Что такое наследование в ООП?

А, наследование! Ну это ж классика, ёпта. Представь себе, что у тебя есть какой-нибудь общий предок, типа «Транспортное Средство». Ну, абстрактная такая хрень, которая может ехать и, допустим, сигналить. И вот от этой штуки ты начинаешь плодить потомков.

Это как если бы твой дед оставил тебе в наследство старую «Волгу» — саму машину (поля) и умение на ней рулить (методы). Ты берешь эту основу и начинаешь её пилить: ставишь спойлер, турбину, магнитолу с караоке. По сути, ты создал новый класс «ПрокачаннаяВолга», который является (is-a) транспортом, но со своими фишками. И тебе не пришлось с нуля изобретать колесо и руль — они уже есть, спасибо деду.

Вот смотри на код, тут всё наглядно:

// Базовый (родительский) класс
class Vehicle {
    protected String brand;

    public Vehicle(String brand) {
        this.brand = brand;
    }

    public void honk() {
        System.out.println("Beep beep!");
    }
}

// Дочерний класс, наследует Vehicle
class Car extends Vehicle {
    private int numberOfDoors;

    public Car(String brand, int doors) {
        super(brand); // Вызов конструктора родительского класса
        this.numberOfDoors = doors;
    }

    public void displayInfo() {
        System.out.println("This is a " + brand + " car with " + numberOfDoors + " doors.");
        honk(); // Можно использовать унаследованный метод
    }
}

Видишь? Класс Car extends (расширяет) Vehicle. Это как будто он говорит: «Я всё, что умеет Vehicle, плюс мои собственные прибамбасы». Бренд и метод honk() достались ему просто так, по наследству. А вот количество дверей — это его личное дело. Конструктор вызывает super(brand) — это типа поклонись предку, передай ему бренд, чтобы он там всё инициализировал как надо.

А теперь про основные фишки, без которых никуда:

• Переопределение методов (Override): Это когда наследнику не нравится, как предок что-то делает. Ну вот сигнал «Beep beep!» — это же прошлый век, ни хуя себе как старомодно.

  class ElectricCar extends Car {
      @Override
      public void honk() {
          System.out.println("Silent electric beep!"); // А вот так — стильно, модно, молодёжно.
      }
  }

  Всё, теперь все электрокары будут пищать по-тихому. Предок в гробу перевернётся, но его уже не спросишь. Главное — аннотацию @Override ставить, чтобы компилятор понимал, что ты специально, а не случайно опечатался.

• Абстрактные классы и методы: Это когда предок — просто хитрая жопа. Он заявляет: «Дети мои, метод honk() должен быть у всех! А КАК его делать — это ваши проблемы, я сам не знаю». И оставляет пустое место. А ты обязан его заполнить, иначе компилятор тебя впиздюрит и скомпилироваться не даст. Доверия ебать ноль к тебе, пока не реализуешь.

• Полиморфизм: А вот это уже магия, ёперный театр. Ты можешь объявить переменную типа Vehicle, а положить в неё объект Car или ElectricCar.

  Vehicle myVehicle = new Car("Ford", 2); // Полиморфизм
  myVehicle.honk(); // Вызовется переопределенный метод, если он есть

  Система смотрит: ага, на самом деле там Car. И вызывает метод honk() от Car (или от ElectricCar, если он ещё дальше переопределён). Это охуенно мощный инструмент. Можно, например, загнать в один список и грузовики, и мотоциклы, и катера — всех, кто унаследован от Vehicle, — и всем разом дать команду honk(). Каждый просигналит по-своему.

• Инкапсуляция и доступ: Тут всё просто. Поля private — это личное, внукам не светит. protected — а вот это уже для семьи, наследники видят и могут использовать. public — вообще всем. Выбирай, что кому показывать, а то получится распиздяйство.

В общем, зачем это всё? Чтобы не изобретать велосипед каждый раз, блядь. Построить чёткую иерархию, где у всего есть логичный предок. Чтобы код был не кучей разрозненных классов, а продуманной системой, где общая логика в одном месте, а частные случаи — в других. И чтобы потом, когда понадобится добавить, скажем, летающий мотоцикл, ты не переписывал половину программы, а просто создал новый класс FlyingMotorcycle extends Vehicle, дописал пару методов — и всё, дело в шляпе. Красота, а не механизм.