Главная цель этих принципов — повысить гибкость архитектуры, уменьшить связанность между её компонентами и облегчить повторное использование кода.
[S]ingle Responsibility Principle (Принцип единственной ответственности)
«У класса должна быть только одна причина для изменения.»
Один класс должен решать только какую-то одну задачу. Он может иметь несколько методов, но они должны использоваться лишь для решения общей задачи. Все методы и свойства должны служить одной цели. Если класс имеет несколько назначений, его нужно разделить на отдельные классы.
Если класс делает слишком много вещей сразу, вам приходится изменять его каждый раз, когда одна из этих вещей изменяется. При этом есть риск сломать остальные части класса, которые вы даже не собирались трогать.
[O]pen/closed Principle (Принцип открытости/закрытости)
«Программные сущности должны быть открыты для расширения, но закрыты для модификации.»
Стремитесь к тому, чтобы классы были открыты для расширения, но закрыты для изменения. Главная идея этого принципа в том, чтобы не ломать существующий код при внесении изменений в программу.
[L]iskov Substitution Principle (Принцип подстановки Барбары Лисков)
«Подклассы должны дополнять, а не замещать поведение базового класса.»
- Типы параметров метода подкласса должны совпадать или быть более абстрактными, чем типы параметров базового метода.
- Тип возвращаемого значения метода подкласса должен совпадать или быть подтипом возвращаемого значения базового метода.
- Метод не должен выбрасывать исключения, которые несвойственны базовому методу. Типы исключений в переопределённом методе должны совпадать или быть подтипами исключений, которые выбрасывает базовый метод.
- Метод не должен ужесточать пред-условия.
- Метод не должен ослаблять пост-условия.
- Инварианты класса должны остаться без изменений. Инвариант — это набор условий, при которых объект имеет смысл.
- Подкласс не должен изменять значения приватных полей базового класса.
[I]nterface Segregation Principle (Принцип разделения интерфейса)
«Клиенты не должны зависеть от методов, которые они не используют.»
Стремитесь к тому, чтобы интерфейсы были достаточно узкими, чтобы классам не приходилось реализовывать избыточное поведение.
[D]ependency Inversion Principle (Принцип инверсии зависимостей)
«Классы верхних уровней не должны зависеть от классов нижних уровней. Оба должны зависеть от абстракций.»
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.