Принципы SOLID
(описание к предыдущему посту)

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

Эти принципы были предложены Робертом С. Мартином (Дядей Бобом), хотя на их формирование повлияли и более ранние работы.

Вот список принципов:

**1. Принцип единственной ответственности (SRP)

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

Когда класс реализует единственную ответственность, изменения в спецификации, скорее всего, затронут меньшее число компонентов — и это упрощает поддержку. Кроме того, снижается связанность между различными компонентами.

Например, можно создать класс UserManager для обработки операций, связанных с пользователями: аутентификации, взаимодействия с базой данных и отправки email‑уведомлений. Если мы изменим, скажем, логику отправки email‑уведомлений, это может повлиять на другие области — например, на аутентификацию пользователей. Такие классы иногда называют «божественными классами» (*God classes*).

2. Принцип открытости/закрытости (OCP)

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

3. Принцип подстановки Барбары Лисков (LSP)

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

4. Принцип разделения интерфейса (ISP)

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

5. Принцип инверсии зависимостей (DIP)

Модули высокого уровня не должны зависеть от модулей низкого уровня; и те, и другие должны зависеть от абстракций. Это поощряет слабосвязанную архитектуру. Кроме того, абстракции не должны опираться на детали — детали должны зависеть от абстракций.