Принцип единственной ответственности ( англ. single-responsibility principle, SRP ) — принцип ООП , обозначающий, что каждый объект должен иметь одну ответственность и эта ответственность должна быть полностью инкапсулирована в класс . Все его поведения должны быть направлены исключительно на обеспечение этой ответственности.

Описание

Термин SRP был введён Робертом С. Мартином в одноимённой статье как часть SOLID , ставших популярными благодаря его книге « Быстрая разработка программ. Принципы, примеры, практика.» . Мартин описал SRP, основываясь на закономерности, описанной Томом ДеМарко и Мейлиром Пейдж-Джонсом и названной связностью .

В SOLID — буква «S» является аббревиатурой, которая образована сокращением от английского названия принципа единственной ответственности(англ. Single Responsibility Principle).

Мартин определяет ответственность как причину изменения и заключает, что классы должны иметь одну и только одну причину для изменений. Например, представьте себе класс, который составляет и печатает отчёт. Такой класс может измениться по двум причинам:

1. может измениться само содержимое отчёта
2. может измениться формат отчёта.

Логично, что оба аспекта этих причин на самом деле являются двумя разными ответственностями. SRP говорит, что в таком случае нужно разделить класс на два новых класса, для которых будет характерна только одна ответственность. Причина, почему нужно сохранять направленность классов на единственную цель в том, что это делает классы более здоровыми. Что касается класса, приведённого выше, если произошло изменение в процессе составления отчёта — есть большая вероятность, что в негодность придёт код, отвечающий за печать.

При разработке различных поведений одного класса часто появляется « Божественный объект », который в ООП считается антипаттерном . Соблюдение принципа единственной ответственности позволяет избегать этого антипаттерна.

Использование

Возникает вопрос, когда стоит использовать этот принцип? Всё же принцип — это не закон и SRP стоит применять в зависимости от того, как изменяется приложение:

• если при изменении кода, отвечающего за одну ответственность, в приложении появляются исправления кода, отвечающего за другую ответственность, то это первый сигнал о нарушении SRP.
• если же изменения кода, отвечающего за одну ответственность, не вносят изменения в код, отвечающий за другую ответственность, то этот принцип можно не применять.

Слепое следование принципу единственной ответственности приводит к избыточной сложности приложения, его поддержки и тестирования. SRP стоит применять только тогда, когда это оправдано. Принцип SRP можно применить только в том случае, когда:

• объекту класса становится позволительно слишком много;
• доменная логика концентрируется только в одном классе;
• любое изменение логики поведения объекта приводит к изменениям в других местах приложения, где это не подразумевалось изначально;
• приходится тестировать, исправлять ошибки, компилировать различные места приложения, даже если за их работоспособность отвечает третья сторона;
• невозможно легко отделить и применить класс в другой сфере приложения , так как это потянет ненужные зависимости.

Объединение ответственностей является общепринятой практикой и в этом нет ничего плохого, до тех пор пока это легко обслуживать. Следование принципу единственной ответственности зависит от функций программного продукта и является труднейшим при проектировании приложений.

В качестве примера нарушения SRP часто приводят ActiveRecord — паттерн, который позволяет легко связать данные объектов и данные из базы данных. В ActiveRecord много ответственностей сконцентрировано в одном месте и поэтому можно утверждать, что ActiveRecord нарушает SRP и тем самым становится антипаттерном. В некоторых случаях это утверждение спорно, так как сам по себе объект, реализующий ActiveRecord, не содержащий никакой бизнес логики, а предоставляющий таблицу из базы данных, имеет лишь одну причину для изменения (изменение таблицы), что не противоречит определением принципа SRP .

Приёмы соблюдения принципа

Следующие приёмы позволяют соблюдать принцип единственной ответственности:

• Разработка через тестирование
• Шаблон « Выделение класса »
• Шаблон « Фасад »
• Шаблон « Proxy »
• DAO

Классическим примером нарушения SRP может служить ситуация, когда системе с бизнес-правилами ( BRMS ) нужно иметь дело с постоянным хранилищем ( ). На первых этапах проектирования таких систем создаётся класс, который обрабатывает бизнес правила и содержит логику работы с базой данных. С нарушением SRP появляются признаки плохого проекта , такие как:

• система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект «снежного кома», затрагивающего другие компоненты системы.
• в результате осуществляемых изменений система разрушается в тех местах, которые не имеют прямого отношения к непосредственно изменяемому компоненту.

Если бы система изначально разрабатывалась через тестирование( TDD ), то этой проблемы могло бы и не возникнуть. Опираясь на тесты, разработчики могут быстрее представить, какая функциональность необходима пользователю. Таким образом, детали класса появляются задолго до окончательной реализации решения, тем самым влияя на дизайн разрабатываемой системы. Но бывает и так, что разработка через тестирование не приводит к применению шаблона « Выделение класса », тогда к системе применяется рефакторинг с применением шаблонов « Фасад », DAO или « Proxy ».

SRP предлагает разделять универсальные классы на конкретные, что сделает их простыми и лёгкими в обслуживании. Подобную идею также выдвигает принцип KISS .

См. также

• GRASP
• Separation of Concerns
• Cohesion
• Chain of responsibility

Примечание

Литература

• Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. — Pearson Education, 2008. — ISBN 978-0-13-608325-2 .

Ссылки