Принципы SOLID — это пять базовых принципов объектно-ориентированного программирования и проектирования, предложенных Робертом Мартином (Robert C. Martin), также известным как Uncle Bob. Эти принципы призваны упростить разработку, сопровождение и расширение программных систем, делая архитектуру гибкой, устойчивой к изменениям и читаемой.

Аббревиатура SOLID расшифровывается следующим образом:

S — Single Responsibility Principle (Принцип единственной ответственности)

Суть: У класса должна быть только одна причина для изменения, то есть он должен выполнять только одну задачу (иметь одну ответственность).

Пояснение:
Класс или модуль должен быть сосредоточен на решении одной конкретной проблемы. Если он выполняет несколько обязанностей, изменения в одной области могут повлиять на другие, нарушая стабильность и сопровождаемость кода.

Пример (нарушение):

class Report {
void generateReport() { /\* логика генерации отчета \*/ }
void printReport() { /\* логика печати \*/ }
void saveToDatabase() { /\* логика сохранения \*/ }
}

Проблема: Класс занимается генерацией, выводом и сохранением — это три разные ответственности.

Решение: Разделить на разные классы — ReportGenerator, ReportPrinter, ReportSaver.

O — Open/Closed Principle (Принцип открытости/закрытости)

Суть: Программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации.

Пояснение:
Код должен позволять добавлять новое поведение без необходимости изменять существующий код. Это достигается через использование абстракций (например, интерфейсов) и полиморфизма.

Пример:

interface PaymentMethod {
void pay();
}
class CreditCard implements PaymentMethod {
public void pay() { /\* оплата картой \*/ }
}
class PayPal implements PaymentMethod {
public void pay() { /\* оплата через PayPal \*/ }
}

Расширяемость: Для добавления нового способа оплаты создается новый класс, без изменения существующих.

L — Liskov Substitution Principle (Принцип подстановки Барбары Лисков)

Суть: Объекты подклассов должны быть взаимозаменяемыми с объектами их суперклассов без нарушения корректности программы.

Пояснение:
Если S — подтип T, то объекты типа T можно заменить на S, и поведение программы останется корректным. Нарушение этого принципа ведёт к ошибкам при использовании наследования.

Пример нарушения:

class Bird {
void fly() { }
}
class Ostrich extends Bird {
void fly() { throw new UnsupportedOperationException(); }
}

Проблема: Страус не умеет летать, но как Bird ожидается, что он может. Нарушается поведение при подстановке.

Решение: Разделить иерархии — FlyingBird и NonFlyingBird.

I — Interface Segregation Principle (Принцип разделения интерфейса)

Суть: Клиенты не должны зависеть от интерфейсов, которые они не используют.

Пояснение:
Лучше создать несколько специализированных интерфейсов, чем один универсальный. Это минимизирует количество методов, которые необходимо реализовывать.

Пример нарушения:

interface Worker {
void work();
void eat();
}
class Robot implements Worker {
public void work() { /\* работает \*/ }
public void eat() { throw new UnsupportedOperationException(); }
}

Проблема: Robot не ест, но обязан реализовывать eat.

Решение:

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

Теперь Robot реализует только Workable.

D — Dependency Inversion Principle (Принцип инверсии зависимостей)

Суть: Зависимости должны строиться от абстракций, а не от конкретных реализаций.
Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракций.

Пояснение:
Это достигается за счёт внедрения зависимостей (dependency injection), когда зависимости передаются через конструктор, методы или свойства, а не создаются внутри класса.

Пример (нарушение):

class EmailSender {
void sendEmail() { /\* логика отправки email \*/ }
}
class Notification {
EmailSender sender = new EmailSender();
void notifyUser() {
sender.sendEmail();
}
}
```python

**Проблема:** Notification жёстко зависит от конкретного класса EmailSender.

**Решение:**

```python
interface Sender {
void send();
}
class EmailSender implements Sender {
public void send() { /\* логика отправки email \*/ }
}
class Notification {
private final Sender sender;
Notification(Sender sender) {
this.sender = sender;
}
void notifyUser() {
sender.send();
}
}

Теперь Notification зависит от интерфейса, а не от конкретной реализации.

Связь между принципами

• SRP обеспечивает фокусировку класса на одной цели.

• OCP даёт возможность расширять поведение без вмешательства в исходный код.

• LSP обеспечивает безопасность при наследовании.

• ISP делает интерфейсы более легковесными и под конкретную задачу.

• DIP облегчает замену зависимостей и тестирование компонентов.

Следование SOLID-принципам помогает создавать устойчивую архитектуру, минимизирует технический долг и облегчает разработку и поддержку больших проектов.