Какие основные принципы объектно-ориентированного программирования (ООП)?

О, смотри-ка, какие принципы ООП нарисовались! Ну что ж, давай разберём эту ебучую матрёшку, но без зауми, а как есть, на пальцах. Четыре кита, на которых всё держится, а потом ещё SOLID подъехал — это как пять заповедей для программиста, который не хочет, чтобы его код через месяц вызывал желание впендюрить монитор об стену.

1. Инкапсуляция

Представь себе банкомат, блядь. Ты не лезешь внутрь, не ковыряешься в его ебучей начинке, не перерезаешь провода, чтобы снять деньги. У него есть чёткая рожа — экран, клавиатура, щель для карты. Вот это и есть публичный интерфейс, сука! Всё остальное — его личное дело, его private-жизнь. Как он там баланс считает, где хранит — похуй. Главное, чтобы по запросу выдавал.

class BankAccount {
    // Вот это вот — спрятано нахуй. Никому не видно. Не твоё собачье дело.
    private double balance;
    private String owner;

    // А вот это — лицо. Через это с ним и общаешься.
    public BankAccount(String owner) {
        this.owner = owner;
        this.balance = 0.0;
    }

    public void deposit(double amount) {
        if (amount > 0) {
            balance += amount;
        }
    }

    public double getBalance() {
        return balance; // Сказал "дай баланс" — получи, но не лезь менять!
    }
}

Суть: Объект — это такой хитрожопый чёрный ящик. Ты кидаешь в него команды через дырки (методы), а что он там внутри делает — его проблемы. Главное, чтобы результат был правильный.

2. Наследование

Ну это вообще классика, ёпта! Как в жизни: был какой-нибудь «УАЗик-буханка» — простая, угловатая, но едет. А потом приходят инженеры и говорят: «А давайте сделаем на её основе внедорожник, но с кондиционером и подогревом жопы!». Новый класс создаётся на основе старого, всё от родителя берёт, но ещё и своё похабное добавляет.

// Базовый класс — как тот самый УАЗ
class Animal {
    String name;
    void makeSound() {
        System.out.println("Some generic sound"); // Мычит как-то неопределённо
    }
}

// А это уже его ушастый потомок
class Dog extends Animal {
    // Переопределил метод — теперь говорит по-собачьи
    @Override
    void makeSound() {
        System.out.println("Woof!");
    }

    // И добавил свою фишку, которой у родителя не было
    void fetch() {
        System.out.println("Fetching the ball...");
    }
}

3. Полиморфизм

Звучит сложно, а на деле — просто пиздец как удобно. Один интерфейс — много форм. Как пульт от телевизора: одна кнопка «Включить», но на Sony он делает одно, на Samsung — другое, а на древнем «Рубине» вообще может искры пустить. Объекты разных классов могут откликаться на один и тот же вызов по-разному.

// Смотри магию: объявляем переменную типа "Животное", а кладём в неё "Собаку"
Animal myAnimal = new Dog();
myAnimal.makeSound(); // А гавкает-то как собака! Выведет "Woof!"

// Или вот: собрали зоопарк в одну кучу
List<Animal> zoo = Arrays.asList(new Dog(), new Cat());
for (Animal a : zoo) {
    a.makeSound(); // Один говорит "Гав", другой "Мяу". Каждый своё!
}

Формы бывают: либо переопределение (как выше), либо перегрузка — когда методы с одним названием, но разными параметрами, как тот самый швейцарский нож.

4. Абстракция

А вот это, блядь, самое интересное! Суть в том, чтобы отбросить всю шелуху и оставить только самую соль. Не нужно описывать машину до последнего винтика, чтобы объяснить, что она «едет». Абстракция — это как чертёж: только основные контуры, без подробностей, как там болтики закручены.

// Абстрактный класс "Фигура". Он не существует в природе, это просто идея.
abstract class Shape {
    // Абстрактный метод — контракт для всех потомков: "Ребята, вы ОБЯЗАНЫ уметь считать площадь!"
    abstract double calculateArea();

    // А вот тут уже готовая логика, которая работает для ВСЕХ фигур
    void printArea() {
        System.out.println("Area: " + calculateArea()); // Считайте как хотите, но результат дайте!
    }
}

// Конкретная реализация — круг
class Circle extends Shape {
    double radius;
    Circle(double r) { radius = r; }

    @Override
    double calculateArea() {
        return Math.PI * radius * radius; // Вот тебе, родитель, площадь круга, доволен?
    }
}

Сделать абстракцию можно через абстрактные классы или интерфейсы — это как два разных способа сказать «делай вот так, а детали — твои проблемы».

Принципы SOLID

А это, сука, уже высший пилотаж! Когда базовые принципы освоил, нужно ещё и SOLID в голове держать, чтобы твой код не превратился в такое монстро, которое и сам через неделю боишься трогать. Пять букв — пять заповедей для адекватного архитектора.

• SRP: Принцип единственной ответственности. Один класс — одна работа. Не надо делать из класса «швейцара-сантехника-бухгалтера». Разделяй и властвуй, епта!
• OCP: Принцип открытости/закрытости. Класс должен быть открыт для расширения (можно добавить новое поведение), но закрыт для модификации (не лезь в уже работающий код).
• LSP: Принцип подстановки Барбары Лисков. Если у тесть есть код, работающий с «Птицей», то он должен спокойно работать и с «Уткой», и с «Пингвином». Потомок не должен ломать логику родителя.
• ISP: Принцип разделения интерфейса. Не делай один здоровенный интерфейс на все случаи жизни. Лучше несколько маленьких и точных. А то получится «интерфейс Бога», который заставляет класс реализовывать кучу ненужного ему говна.
• DIP: Принцип инверсии зависимостей. Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те, и другие должны зависеть от абстракций. Короче, говори не с конкретной «MySQL-базой», а с абстракцией «хранилище данных». Тогда сменить базу будет не пиздец, а пара движений.

Вот и вся философия, блядь. Освоишь эти принципы — будешь писать код, который не стыдно показать и который не развалится от первого же чиха. А не освоишь... ну, что ж, будешь потом героически ебаться с легаси, которое и понять-то невозможно. Выбор за тобой!