Принципы SOLID

Эти принципы направлены на создание программного обеспечения, которое легко понимать, расширять и модифицировать.

Расшифровка принципов SOLID:

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

   • Определение: Каждый класс или модуль должен иметь одну и только одну причину для изменения, то есть одну ответственность.

   • Пример: Класс UserService должен отвечать только за бизнес-логику пользователей, а не за отправку email или логирование в файл. Эти задачи нужно вынести в отдельные классы (EmailService, Logger).

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

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

   • Пример: Вместо того чтобы изменять существующую функцию для добавления нового типа, лучше использовать полиморфизм. Добавляется новый класс, который реализует общий интерфейс, а основная логика работает с этим интерфейсом.

3. L: Принцип подстановки Лисков (Liskov Substitution Principle)

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

   • Пример: Если у вас есть функция, принимающая базовый класс Bird, она должна корректно работать и с его наследником Penguin (который не умеет летать), не ломаясь из-за этого.

4. I: Принцип разделения интерфейсов (Interface Segregation Principle)

   • Определение: Много специализированных интерфейсов лучше, чем один универсальный. Клиенты не должны зависеть от методов, которые они не используют.

   • Пример: Вместо большого интерфейса IMultiFunctionDevice с методами print(), scan(), fax(), лучше создать отдельные интерфейсы IPrinter, IScanner. Тогда старый принтер сможет реализовать только IPrinter.

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

   • Определение:

     1. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.

     2. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

   • Пример: Сервис (UserService) не должен напрямую создавать экземпляр репозитория для работы с БД (UserRepository). Вместо этого он должен зависеть от абстракции (интерфейса IUserRepository). Конкретная реализация (например, PostgresUserRepository) внедряется извне (через конструктор), часто с помощью DI-контейнера, как в Nest.js.

Вывод: Следование принципам SOLID приводит к созданию кода с низкой связанностью и высокой связностью, что облегчает его тестирование, рефакторинг и развитие в долгосрочной перспективе.