Single Responsibility Principle

Цикл статей о SOLID принципах

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs. ООП)
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle
• О принципах проектирования

--------------------------------------------------

Принцип единственной обязанности (Single-Responsibility Principle, SRP): У класса должна быть только одна причина для изменения.
Роберт Мартин. Принципы, паттерны и практики гибкой разработки

Существует ряд патологических случаев нарушения принципа единственной обязанности, которые будут очевидны сегодня практически любому. Классы бизнес-логики, которые знают о пользовательском интерфейсе или о базе данных; класс windows-сервиса c кучей бизнес-логики; статические утилитные классы, изменяющие глобальное состояние и т.п.

При этом нарушение SRP бывают как на уровне классов/модулей, так и на уровне подсистем и приложений. Классическим примером из моей практики являются два вопиющих нарушения SRP на уровне приложений: использование Windows Forms приложения в качестве WCF сервиса, и необходимость взаимодействия виндового сервиса с пользователем через Message Box-ы.

Приведенные выше случаи не столько нарушают SRP, сколько противоречат здравому смыслу. А как быть с более тонкими проблемами, когда один разработчик говорит, что дизайн хорош, а для другого он серьезно «попахивает» и вам хочется найти весомые аргументы против текущего решения?

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

Для чего нужен SRP?

SRP предназначен для борьбы со сложностью. На самом деле, любой принцип или паттерн проектирования предназначен для этого. Когда в нашем приложении всего 200 строк, то дизайн как таковой вообще не нужен. Достаточно аккуратно написать 5-7 методов и все будет хорошо. Проблемы возникают, когда система растет и увеличивается в масштабах. Поскольку сложность растет не линейно при увеличении размера приложения приходится подходить к дизайну более осмысленно, вспоминать всякие страшные слова, типа абстракции и сокрытия информации, лучше продумывать обязанности каждого класса, чтобы у разработчика сегодня и через год была возможность сосредоточиться на главной проблеме класса/модуля и проигнорировать второстепенные детали.

ПРИМЕЧАНИЕ
Подробнее о дизайне и критериях его качества читайте в заметках: Критерии плохого дизайна и О дизайне.

SRP и борьба со сложностью

Давайте рассмотрим такой пример. R# API предоставляет абстракцию под названием Context Actions (кстати, нечто подобное появится и в API Visual Studio 2015!). Это такая штука, которая появляется при нажатии Alt + Enter и с ее помощью можно делать много всего интересного: удалять ненужные выражения, преобразовывать LINQ-запросы и т.п.

Контекстные действия представлены базовым классом ContextActionBase, который содержит следующие ключевые члены:

public abstract class ContextActionBase
{
    public abstract void Execute();
    public abstract bool IsAvailable();
    public abstract string Text { get; }
}

(На самом деле интерфейс R# API несколько отличается от этого, но суть именно такая.)

Когда я начинал разрабатывать плагин для упрощения контрактного программирования, то я начал с реализации контекстных действий по добавлению предусловий для проверки аргументов метода на null: с класса AddRequiresContextAction.

Поскольку изначально в голову приходят лишь небольшое число граничных случаев, то вначале класс AddRequiresContextAction содержал всю логику: логику по определению доступности добавления предусловия (например, что аргумент метода является ссылочного типа, он еще не проверен на null и т.п.), а также логику по добавлению предусловия для текущего класса.

Нарушал ли данный класс SRP? Сложно сказать. И да, и нет. С одной стороны, сам интерфейс базового класса говорит о необходимости выполнения нескольких действий, с другой стороны у класса на тот момент было всего три метода, каждый из которых отвечал за определенный аспект поведения, а их реализация была довольно простой. Можно сказать, что данный класс был «крепко связанный» (highly cohesive), а значит нарушать SRP не мог.

Но по мере того, как росло мое понимание предметной области добавлялось все больше и больше граничных условий. Со временем я понял, что если аргумент уже проверяется с помощью if-throw, то контекстное действие по добавлению Contract.Requires должно отсутствовать; что действие также должно быть недоступным, если значение аргумента по умолчанию равно null, что нужно учитывать еще и абстрактные классы и т.п. В результате мой класс AddRequiresContextAction начал изменяться и граф вызовов его внутренних методов стал выглядеть следующим образом:

Теперь даже по рисунку видно, что в классе две группы обязанностей, которые тесно взаимодействуют внутри, но никак не взаимодействуют между собой. Очевидно, что у данного класса появилось две ярко выраженные ответственности: проверка допустимости действия и его исполнение, которые не были столь очевидны до этого. В результате, я выделил два дополнительных класса: AddRequiesAvailability и AddRequiresExecutor, которые отвечают за «доступность» действия и за его «выполнение».

Более того, со временем даже эти два класса были разбиты на более мелкие составляющие, так что один класс в результате «вырос» в целый граф взаимодействующих объектов:

(Текущая версия класса AddRequiresContextAction выглядит так).

А в чем проблема в исходном решении? Зачем нужно было выделять два дополнительных класса? Чтобы классы соответствовали принципу, описанному дядюшкой Бобом?

Когда класс разрастается, он просто перестает помещаться в голове. Навигация затрудняется, на глаза попадаются ненужные детали, связанные с другим аспектом, в результате, количество понятий начинают превышать священные 7 ± 2 и мы начинаем терять контроль над кодом.

Я хочу иметь возможность сосредоточиться на сложных аспектах системы по отдельности, поэтому когда мне становится сложно это делать, я начинаю разбивать классы и выделять новые.

SRP в реальной жизни

Я честно признаюсь, что не понимаю принцип SRP в формулировке от «дядюшки» Боба и его метафору с «осью изменения» (мне понятна эта метафора в контексте Open-Closed Principle, но об этом мы поговорим в следующий раз.) Определение довольно запутанное, да и пояснение лишь сбивает с толку:

«В контексте принципа SRP мы будем называть обязанностью причину изменения. Если вы можете найти несколько причин для изменения класса, то у такого класса более одной обязанности.
…

Следует ли разделить эти обязанности? Все зависит от того, как именно изменяется приложение.

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

Отсюда вытекает следствие. Ось изменения становится таковой, только если изменение имеет место. Неразумно применять SRP – как и любой другой принцип, – если для того нет причин.»

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

Для меня SRP – это способ поиска скрытых абстракций, достаточно сложных, чтобы им отвели отдельную именованную сущность и спрятали в их недрах все детали. Разделение классов на составляющие диктуются не «осями изменений», а здравым смыслом и попыткой справиться с нарастающей сложностью системы.

Дополнительные ссылки

• О книге Боба Мартина «Принципы, паттерны и практики гибкой разработки»
• Критерии плохого дизайна
• О дизайне