Принципы проектирования программного обеспечения (SOLID) |

ТВЕРДЫЙ
S – Принцип единоличной ответственности
O – принцип «открыто-закрыто»
L — принцип подстановки Лисков
I – Принцип разделения интерфейсов
D – Принцип инверсии зависимостей

Принцип единой ответственности (SRP)
У класса должна быть единственная причина для изменения, а это означает, что у класса должна быть только одна работа. Если у нас есть две причины изменить класс, мы должны разделить функциональность на два класса.
Каждый класс будет нести только одну ответственность, и в будущем, если нам нужно будет внести одно изменение, мы сделаем это в классе, который его обрабатывает.

Принцип открытого-закрытого (OCP)
Программный модуль (классы, функции и модули) должен быть открыт для расширения и закрыт для модификации. Учтите это при написании своих классов, чтобы убедиться, что когда вам нужно расширить их поведение, вам нужно не изменять класс, а расширять его.
Этот принцип применим при изменении программного обеспечения, но он должен поддерживать обратную совместимость, регрессионное тестирование и т. д.
Принцип Open Close может быть обеспечен за счет использования абстрактных классов и конкретных классов для реализации их поведения.
Некоторыми частными случаями OCP являются шаблон шаблона и шаблон стратегии.

Принцип замещения Лискова (LSP)
Подтипы должны быть полностью заменяемыми для своих базовых типов.
Убедитесь, что новые производные классы расширяют базовые классы без изменения их поведения.
Новые производные классы должны иметь возможность заменять базовые классы без каких-либо изменений в коде.

Принцип разделения интерфейсов (ISP)
Множество конкретных интерфейсов лучше, чем один общий интерфейс.
Клиента никогда не следует заставлять реализовывать интерфейс, который он не использует, или клиентов нельзя заставлять зависеть от методов, которые они не используют.
Добавляйте в интерфейс только те методы, которые должны быть там. Если мы добавим методы, которых не должно быть, классы, реализующие интерфейс, также должны будут реализовать эти методы.
Интерфейсы, содержащие неспецифические для него методы, называются загрязненными или толстыми интерфейсами. Мы должны избегать их.

Принцип инверсии зависимости
Мне все равно как, просто дай мне то, что я хочу
Сущности должны зависеть от абстракций, а не от конкретики. В нем говорится, что модуль высокого уровня не должен зависеть от модуля низкого уровня, но они должны зависеть от абстракций.
Также известен как «инверсия управления».
Фабрики и абстрактные фабрики могут использоваться в качестве фреймворков зависимостей, но для этого существуют специализированные фреймворки, известные как Inversion of Control Container.