SOLID Принцип единственной ответственности
sergey shishkin"Single Responsibility Principle (SRP)":
Один участок кода должен меняться только в ходе реализации одной цели. Если участок кода реализует две задачи и меняется для разного использования, то следует продублировать этот участок по экземпляру для каждой цели. Это очень важно, потому что требует отступить от общепринятого принципа устранения дублирования.
Целью этого принципа является устранение неявно вносимых ошибок, получаемых из-за того, что в разработке для блока кода существуют следующие инварианты:
- ⟨1.1⟩, ⟨1.2⟩, ⟨1.3⟩
- если для одного из мест использования требуется изменение блока кода, а для другого места использования требуется прежнее поведение блока кода, то необходимо создание копии блока кода с последующей её модификацией (или обобщение блока кода дополнительными параметрами, обеспечивающих разное поведение),
- если есть места использования блока кода, которые не важны для текущей задачи, решаемой программистом, то ему очень легко забыть о проверке совместности с этими местами использования вносимого в этот блок кода изменения.
Поэтому все места использования должны располагаться в зоне "Single Responsibility" единой ответственности, то есть изменяться и учитываться разом для любой решаемой программистом задачи.
Принцип относится как к участку кода, так и к компоненту, библиотеке, программе, комплексу программ, используемых в нескольких местах.
В многих источниках приводят пример класса с одной только "функцией" как идеал SRP и класс "божественного объекта", совмещающий все функции приложения, как антипаттерн. IMHO класс с одной только "функцией" это требование преждевременной оптимизации архитектуры кода, побуждающее на пустом месте писать множества классов (кодовых сущностей), при этом забывая, что отсутствие более одного места использования позволяет программисту быстрее оценить малое количество расположенного локально (в одном классе) взаимодействующего кода, чем анализировать внешние связи разрозненных кодовых сущностей, ответственных за свою "функцию". "Божественный объект" для крошечного приложения тоже вроде не сильный криминал — он позволяет запустить разработку: выделить все необходимые сущности и, записав их рядом, отделить от внешних объектов стандартной библиотеки и внешних модулей (создать живую клеточку и обособить её мембраной). В процессе роста и развития проекта существует множество приемов помогающих следовать SRP, один из них разделения на классы и минимизация количества "функций", за которые каждый класс отвечает (деление клеточек и их специализация в организме).
Здесь хотелось бы выписать набор приемов поддержания SRP, но эта работа пока не завершена (надеюсь "руки дойдут"). Из очевидных областей, где можно поискать эти приемы:
- паттерны проектирования;
- использование разных специализированных веток компонента в отличие от создания компонента удовлетворяющего всем способам применения (fork на GitHub).