Каковы основные принципы SOLID в Java?

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

Первый принцип — Принцип единственной ответственности (SRP)

Короче, один класс — одна работа. Всё просто, как палка. Не надо делать из класса такого универсального солдата, который и в БД пишет, и логирует, и чайник ставит. Это пиздец как неудобно.

Смотри, как бывает у распиздяев:

class UserService {
    public void saveUser(User user) {
        // ... сохранение в БД
    }
    public void logError(String message) {
        // ... запись в лог-файл
    }
}

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

А теперь как надо, по-человечески:

class UserRepository { // Этот чувак ТОЛЬКО за данные. Ничего больше.
    public void save(User user) { /*...*/ }
}

class Logger { // А этот мудак — ТОЛЬКО за логи. Молча в файл строчит.
    public void log(String message) { /*...*/ }
}

class UserService { // А этот уже начальник. Координирует.
    private UserRepository repository;
    private Logger logger;
    public void saveUser(User user) {
        try {
            repository.save(user);
        } catch (Exception e) {
            logger.log(e.getMessage()); // Позвал специалиста для работы
        }
    }
}

Вот! Каждый занимается своим делом. Если логи сдохнут — чини Logger. Не надо ковыряться в логике сохранения пользователей. Элементарно, Ватсон!

Второй принцип — Принцип открытости/закрытости (OCP)

Суть в том, что твой код должен быть как хороший конструктор: чтобы добавить новую детальку, тебе не нужно ломать старые. Ты просто прикручиваешь новую.

Представь, у тебя есть система, которая считает площадь фигур. Если ты для каждой новой фигуры (треугольник, трапеция) будешь лезть в один общий метод и дописывать туда if-else, то ты — пидарас шерстяной. Рано или поздно этот метод превратится в неподдерживаемое говно.

Надо делать на интерфейсах. Объявил интерфейс Shape с методом calculateArea(). Потом делаешь class Circle implements Shape, class Square implements Shape. Чтобы добавить Triangle, ты просто создаёшь новый класс Triangle implements Shape. Старый код, который площади считает, даже не узнает, что ты что-то добавил. Он работает с абстракцией. Красота!

Третий принцип — Принцип подстановки Барбары Лисков (LSP)

Это про наследование. Если у тебя класс Dog наследуется от Animal, то везде, где программа ожидает Animal, она должна спокойно работать с Dog. И не должно быть сюрпризов.

Классический пример пиздеца — это когда Square наследуется от Rectangle. У прямоугольника есть методы setWidth() и setHeight(). А у квадрата ширина и высота всегда равны. Получается, что если ты в коде, работающем с Rectangle, подсунешь ему Square и начнёшь менять ширину, то высота тоже изменится. И вся твоя логика ебется об асфальт. Это и есть нарушение LSP. Наследник не должен ломать поведение родителя. Если ломает — значит, наследование тут не годится, иди нахуй, придумывай другую архитектуру.

Четвёртый принцип — Принцип разделения интерфейса (ISP)

Не заставляй клиента зависеть от того, что ему не нужно. Это как если бы тебе в комплекте с новым телефоном прилагался бы ещё и набор для вышивания крестиком. Нахуя?

Смотри на этот ужас:

interface Worker {
    void work();
    void eat();
    void sleep();
}

Теперь представь, что у тебя есть класс Robot. Он должен реализовать этот интерфейс. И что? Он вынужден реализовывать методы eat() и sleep(). А роботы не едят и не спят! Это же бред, ёпта! Ты пишешь пустые методы или кидаешь исключения. Код воняет.

А теперь сделаем по-умному:

interface Workable {
    void work();
}
interface Eatable {
    void eat();
}
interface Sleepable {
    void sleep();
}

class Human implements Workable, Eatable, Sleepable { /*...*/ } // Человеку всё нужно
class Robot implements Workable { /*...*/ } // Роботу только работать

Вот! Каждый берёт только то, что использует. Чисто, аккуратно, без насилия.

Пятый принцип — Принцип инверсии зависимостей (DIP)

Это, блядь, самый важный, возможно. Высокоуровневые модули не должны зависеть от низкоуровневых. Оба должны зависеть от абстракций. Звучит заумно, но на деле просто.

Не пиши так: class NotificationService { private EmailService emailService; ... } Потому что если завтра тебе понадобится слать SMS, ты будешь переписывать NotificationService.

Пиши так:

interface MessageService { // Абстракция
    void sendMessage(String message);
}

class EmailService implements MessageService { /*...*/ } // Деталь 1
class SMSService implements MessageService { /*...*/ }  // Деталь 2

class NotificationService { // Верхнеуровневый модуль
    private MessageService service; // Зависит от абстракции!
    public NotificationService(MessageService service) { // Вот она, инверсия!
        this.service = service;
    }
    public void notify(String message) {
        service.sendMessage(message); // Ему похуй, что там — email или SMS
    }
}

Теперь ты можешь в NotificationService запихнуть что угодно, что реализует MessageService. И для тестирования ты можешь заглушку (mock) подсунуть. Гибкость — овердохуища!

Итог

Следовать SOLID — это не для галочки. Это чтобы через полгода, когда придёт новый чувак (или ты сам, забывший всё), он не сказал, глядя на твой код: «Какой мудак это писал?». А сказал бы: «А, тут всё понятно, чётко». Код становится модульным, тестируемым и, что главное, его не страшно менять. А в нашей работе без этого — никуда.