Многоликий принцип единственности ответственности

Этот материал является кросс-постом

Кажется, любой "солидный" программист знает что такое SOLID вообще и принцип единственности ответственности (SRP) в частности.

Когда речь заходит об SRP, я всегда уточняю, что именно имеет ввиду мой собеседник. Потому что у SRP существует как минимум пять разных формулировок и три интерпретации. И я не думаю, что подобная эмм…​ штуковина является хорошим руководством по разработке ПО.

Формулировки SRP

Для начала приведу неверную, но самую популярную формулировку:

Класс должен делать одну вещь

— народ

Которой вторит и русская википедия:

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

— Википедия, https://ru.wikipedia.org/wiki/SOLID_(объектно-ориентированное_программирование)

Хотя английская версия той же статьи приводит одну из формулировок Мартина.

Вообще, такой принцип есть - это один из принципов философии Unix. Но сам Мартин пишет в Чистой Архитектуре, что это не SRP:

It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing.

Make no mistake, there is a principle like that. […​] But it is not one of the SOLID principles — it is not the SRP.

— Robert C. Martin, Clean Architecture

Сам Мартин формулирует SRP тремя разными способами:

Формулировка 2003 года

The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change

— Robert C. Martin, Agile software development Principles Patterns and Practices

Формулировка 2014 года

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

— Robert C. Martin, The Single Responsibility Principle

Формулировка 2018 года

A module should be responsible to one, and only one, actor

— Robert C. Martin, Clean Architecture

Чтобы понять, что у них общего, мне потребовалось по три прочтения всех публикаций Мартина об SRP. Вы же сэкономите день-два жизни и получите ответ за пятнадцать минут, если дочитаете пост до конца.

Для начала рассмотрим как анкл Боб объясняет SRP последние двадцать лет.

Объяснения SRP

Agile software development Principles Patterns and Practices, 2003

Любопытный факт - SRP появился на восемь лет позже остальных принципов SOLID, и изначальный порядок был другой - OLDI. А акроним SOLID придумал не анкл Боб, а Майкл Фэзерс.

Впервые SRP появился в Agile software development Principles Patterns and Practices. В этой книге Мартин пояснял его на примере разделения кода различных функций программы:

Consider the bowling game from Chapter 6. For most of its development the Game class was handling two separate responsibilities. It was keeping track of the current frame, and it was calculating the score. In the end, RCM and RSK separated these two responsibilities into two classes. The Game kept the responsibility to keep track of frames, and the Scorer got the responsibility to calculate the score. (see page 85.)

— Robert C. Martin, Agile software development Principles Patterns and Practices

Clean Code, 2008

Пояснять SRP на примере разделения кода по функциям программы Мартин продолжает и в Clean Code:

public class SuperDashboard extends JFrame implements MetaDataUser {
    public Component getLastFocusedComponent()
    public void setLastFocused(Component lastFocused)
    public int getMajorVersionNumber()
    public int getMinorVersionNumber()
    public int getBuildNumber();
}

The seemingly small SuperDashboard class in Listing 10-2 has two reasons to change. First, it tracks version information that would seemingly need to be updated every time the software gets shipped. Second, it manages Java Swing components (it is a derivative of JFrame, the Swing representation of a top-level GUI window)

— Robert C. Martin, Clean Code

The Clean Coder, 2011

Затем в The Clean Coder анкл Боб иллюстрирует SRP уже примером разделения аспектов реализации (пользовательского интерфейса и бизнес-правил):

There is a design principle called the Single Responsibility Principle (SRP). This principle states that you should separate those things that change for different reasons, and group together those things that change for the same reasons. GUIs are no exception.

The layout, format, and workflow of the GUI will change for aesthetic and efficiency reasons, but the underlying capability of the GUI will remain the same.

[...]

Design experts have been telling us for decades to separate our GUIs from our business rules.

— Robert C. Martin, The Clean Coder

The Single Responsibility Principle, 2014

В следующей публикации о SRP анкл Боб уже напрямую использует термин "разделение аспектов [реализации]" (separation of concerns):

Two years later, Edsger Dijkstra wrote another classic paper entitled On the role of scientific thought. in which he introduced the term: The Separation of Concerns. [...] This is the reason we do not put SQL in JSPs. This is the reason we do not generate HTML in the modules that compute results. This is the reason that business rules should not know the database schema. This is the reason we separate concerns.

— Robert C. Martin, https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Но здесь же, Мартин впервые объясняет SRP совсем в другом ключе:

And this gets to the crux of the Single Responsibility Principle. This principle is about people.

When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function.

— Robert C. Martin, https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Здесь уже речь идёт о разделении кода по людям.

Clean Architecture, 2018

В окончательной же форме это объяснение появляется ещё через четыре года в Clean Architecture:

A module should be responsible to one, and only one, actor

— Robert C. Martin, Clean Architecture

Действующим лицом (actor) в этом случае является группа стейкходеров (людей так или иначе причастных к программе и её созданию) с одинаковыми потребностями.

Шестая формулировка SRP

Мне кажется более понятной шестая (уже моя) формулировка SRP:

Модуль должен отвечать за реализацию требований одного стейкхолдера.

— Алексей Жидков, Многоликий принцип единственности ответсвенности

Эта формулировка привязывается ко вполне определённому понятию - "требование". На мой взгляд, термин "требование" вызывает намного меньше разночтений, чем "действующее лицо". "Действующее лицо" - крайне неудачный термин, так как он чаще встречается в значении "пользователь программы", популяризированном UML-ем.

В моей формулировке понятно, почему надо разделять модули хранения данных и представления. Одни специфицируются человеком выполняющим роль администратора БД, а другие - человеком, выполняющим роль дизайнера интерфейсов. Также понятно и почему надо разделять модули, отвечающие за реализацию функций CFO и COO - требования к ним определяется разными людьми из разных отделов.

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

Ни эта, ни любая другая формулировка SRP не даёт программистам практического руководства к действию в каждодневной работе. Может быть, будет полезнее разбить SRP на несколько практических рекомендаций? Например:

1. формируйте направленный ациклический граф зависимостей между модулями;

2. разделяйте ввод-вывод (в том числе GUI) и бизнес-правила;

3. разделяйте код реализующий разные функции системы;

4. пишите тесты. В тестах мокайте только внешние системы, а system under test создавайте "руками" (а не с помощью DI-контейнера).

Эти рекомендации не нуждаются большом предварительном проектировании с определением стейкхолдеров и требований. И следование им можно контролировать механически.

Применение таких рекомендаций в каждодневной работе доступно намного более широкому кругу программистов и также даст поддерживаемую и стабильную систему на выходе.

Помимо приведенных, есть ещё одна важная рекомендация: разделяйте "стандартную библиотеку" (домен) и "скрипты" (функции) приложения. Об этом пишут и Мартин в Clean Architecture - разделение сущностей и интеракторов, и Эванс в DDD - разделение сервисов приложения и сущностей и доменных сервисов. Но ни они, ни я не можем дать объективного критерия, по которому можно следить за соблюдением этой рекомендации механически. Поэтому я не включаю её в ряд простых и понятных.

На суку висит мочало, начинаем всё сначала

SOLID relevance, 2020

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

Это было отличное объяснение развития событий. Пока Мартин не написал свой последний пост на тему SRP. В нём он снова откатился к разделению только по аспектам:

It is hard to imagine that this principle is not relevant in software. We do not mix business rules with GUI code. We do not mix SQL queries with communications protocols.

— Robert C. Martin, https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html

Если посмотреть на историю объяснений SRP с высоты "птичьего полёта", то становится видно что анкл Боб постоянно скачет между этими критериями декомпозиции кода:

История интерпретаций SRP

* В Agile software development Principles Patterns and Practices был и другой пример в главе про SRP.

Two different applications use the Rectangle class. One application does computational geometry. It uses Rectangle to help it with the mathematics of geometric shapes. It never draws the rectangle on the screen. The other application is graphical in nature. It may also do some computational geometry, but it definitely draws the rectangle on the screen.

— Robert C. Martin, Agile software development Principles Patterns and Practices

Глядя на этот пример (из 2021 года) можно прийти к выводу, что у разных приложений будут разные пользователи (один из видов действующих лиц) и методы draw и area реализуют требования разных действующих лиц.

** В Clean Architecture разделение по аспекту реализации тоже присутствует (метод save, определяемый CTO). Но в этой книге Мартин уже явно не проговаривает необходимость разделения по аспектам. В сочетании с нетипичным значением слова actor, это приводит к тому, что такое объяснение можно проинтерпретировать как декомпозицию только на основе пользователей программы. Это может стать четвёртой интерпретацией SRP, но в жизни я её пока не встречал.

Разделение по функциональности и аспектам реализации программы - это не две разные точки зрения на один принцип. Это два разных принципа декомпозиции, которые ведут к разным результатам.

Разделение кода по функциональности != разделению кода по аспектам реализации

Можно разделять SQL и JSP и всё ещё использовать один и тот же код в разных функциях и ломать функции одних пользователей при модификации функций других пользователей.

И наоборот, можно завести по микросервису для каждого пользователя или функции системы и собрать в один метод и парсинг json-а, и бизнес-правила, и выполнение SQL-запросов. В итоге получить хрупкий код, который трудно поддерживать.

Аспекты реализации функциональности и сама функциональность - ортогональные оси декомпозиции кода.

SRP нарушает одну из собственных интерпретаций и смешивает различные аспекты дизайна программ. Зачем анкл Боб объединил два разных принципа в один - я не понимаю. Возможно, он сам не сразу понял, что код надо разделять и по функциональности, и по аспектам реализации, а когда понял - SOLID стал уже брендом, который было жаль терять.

Можем ли мы полагаться на принцип, формулировка и интерпретация которого меняется каждые три года? Я думаю нет.

Нам нужны новые принципы

В итоге мы приходим к тому, что:

• вообще, не очень понятно, что такое SRP. Разные разработчики понимают под этой аббревиатурой разные принципы дизайна. Даже сам Мартин постоянно по-разному формулирует и иллюстрирует SRP;

• то, что мне кажется Единственно Верной Версией SRP, невозможно использовать на практике. Потому что в реальной жизни необходимую для этой версии аналитику никто не делает.

• а если бы и делали, то SRP-идеал всё равно был бы недостижим. Так как у значительной части кода будет как минимум две причины для изменения - требования к функциональности и требования к способу реализации.

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

Тем не менее, в SOLID заключено много хороших и полезных идей, поэтому я не предлагаю упразднить его - я предлагаю его реставрировать. Актуальные идеи вычленить, уточнить и проиллюстрировать хорошими примерами. То, что потеряло свою значимость - убрать.

И главное - не загонять себя в рамки того, чтобы из первых букв новых принципов можно было составить красивый акроним.