SOLID
SOLID (сокр. от англ. single responsibility, open-closed, Liskov substitution, interface segregation и dependency inversion) в программировании — мнемонический акроним, введённый Майклом Фэзерсом (Michael Feathers) для первых пяти принципов, названных Робертом Мартином в начале 2000-х, которые означали пять основных принципов объектно-ориентированного программирования и проектирования.
Нарушают SOLID принципы:
enum
switch
if-else-if
операторы приведения типа
new
S – The Single Responsibility Principle .
Название: Принцип единственной ответственности.
Определение: У класса/модуля должна быть лишь одна причина для изменения.
Смысл принципа: Борьба со сложностью, важность которой резко возрастает при развитии логики приложения.
Краткое описание: Любой сложный класс должен быть разбит на несколько простых составляющих, отвечающих за определенный аспект поведения, что упрощает как понимание, так и будущее развитие.
Типовые примеры нарушения: 1) смешивание логики и инфраструктуры: бизнес-логика смешана с представлением, слоем персистентности, находится внутри WCF или windows-сервисов и т.п. 2) класс/модуль решает задачи разных уровней абстракции: вычисляет CRC и отправляет уведомления по электронной почте; разбирает json-объект и анализирует его содержимое и т.п.
Anti-SRP – Принцип размытой ответственности. Чрезмерная любовь к SRP ведет к обилию мелких классов/методов и размазыванию логики между ними.
O – The Open-Closed Principle
Название: Принцип Открыт-Закрыт
Определение: Программные сущности (классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации.
Смысл: ограничить распространение изменений минимальным числом классов/модулей; позволить вести параллельную разработку путем фиксации интерфейсов классов и открытости реализаций.
Краткое описание: Максимально использовать интерфейсы вместо классов. Закрытость модулей означает стабильность интерфейса и возможность использования классов/модулей клиентами. Открытость модулей означает возможность внесения изменений в поведении, путем изменения реализации или же путем переопределения поведения в наследниках. Борьба с изменениями заключается в ограничении количества изменений минимальным числом классов/модулей и не подразумевает возможность изменения поведения без перекомпиляции. На практике требуемая «гибкость» обеспечивается за счет наследования и сопоставления с образцом (pattern matching), в зависимости от того, какую операцию мы хотим упростить – добавление нового подтипа в иерархию наследования или добавление новой операции в семейство типов.
Типичные примеры нарушения: размазывание информации об иерархии типов по всему приложению.
Anti-OCP – Принцип фабрики-фабрик: Чрезмерная любовь к OCP ведет к переусложненным решениям с чрезмерным числом уровней абстракции.
L – The Liskov Substitution Principle
Название: Принцип замещения Барбары Лисков
Определение: Должна быть возможность вместо базового типа подставить любой его подтип.
Смысл: При наследовании мы не должны изменять(вмешиваться) поведение нашего "родителя класса" (лучше использовать интерфейс в качестве родителя). Реализуйте наследование подтипов правильно.
Краткое описание: для корректной реализации отношения «ЯВЛЯЕТСЯ», наследник может ослаблять предусловие и усиливать постусловие (требовать меньше и гарантировать больше), при этом инварианты базового класса должны выполняться наследником. При нарушении этих правил подстановка экземпляров наследника в метод, принимающий базовый класс будет приводить к непредсказуемым последствиям.
Типичные примеры нарушения: несогласованное поведение наследников, что приводит к необходимости приводить экземпляры базового класса к конкретным типам наследников.
Anti-LSP – Принцип непонятного наследования. Данный анти-принцип проявляется либо в чрезмерном количестве наследования, либо в его полном отсутствии, в зависимости от опыта и взглядов местного главного архитектора
I – Interface Segregation Principle
Название: Принцип разделения интерфейсов
Определение: клиенты не должны вынужденно зависеть от методов, которыми не пользуются.
Смысл: класс должен предоставлять удобный интерфейс с точки зрения его разнообразных клиентов.
Краткое описание: В интерфейсе не должно быть методов которые не будут использовать его наследники !! Если есть такой интерфейс , то его надо разбить на два интерфейса!!. Интерфейс класса должен быть цельным и согласованным не зависимо от числа клиентов. Несколько разных клиентов вполне могут использовать лишь подмножество методов класса, до тех пор, пока интерфейс класса будет оставаться согласованным. Проблемы появляются тогда, когда интерфейс класса начинает распухать или появляются разные методы с похожей семантикой лишь для того, чтобы ими было удобно пользоваться определенным клиентам.
Типичные примеры нарушения: 1) класс или интерфейс содержит несколько методов со схожей семантикой, которые используются разными клиентами; 2) интерфейс класса слишком разнороден и содержит методы, отвечающие за слабосвязанные операции.
Anti-ISP – Принцип тысячи интерфейсов. Интерфейсы классов разбиваются на слишком большое число составляющих, что делает их неудобными для использования всеми клиентами.
D – The Dependency Inversion Principle
Название: Принцип инверсии зависимостей
Определение: Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций.
Смысл: сделать ключевые и/или изменчивые зависимости класса явными.
Краткое описание: Между слоями(например бизнес логикой и базой данных) желательно использовать интерфейс вместо класса. Слишком большое число зависимостей класса говорит о проблемах в дизайне. Возможно класс делает слишком многое, или же текущий класс не удачен, что приводит к необходимости дергания по одному методу у слишком большого числа зависимостей. Любой объектный дизайн представляет собой некоторый граф взаимодействующих объектов, при этом некоторые зависимости являются частью реализации и должны создаваться напрямую (композиция), а некоторые – передаваться ему извне (агрегация). Выделять зависимости особенно полезно, когда они являются изменчивыми (завязаны на окружения), или же представляют собой некоторую форму «стратегий».
Типичные примеры нарушения: использование синглтонов, сервис-локаторов или же создание ключевых зависимостей класса по ходу дела в закрытых методах.
Anti-DIP – Принцип инверсии сознания или DI-головного мозга. Интерфейсы выделяются для каждого класса и пачками передаются через конструкторы. Понять, где находится логика становится практически невозможно.