Comments 8
Я не вижу противоречия разных формулировок, потому что разные формулировки говорят о разных уровнях.
В книге Clean Architecture речь идёт о крупномасштабной структуре программы, и на таком уровне модуль действительно может закрывать потребности одного actor (действующего лица):
A module should be responsible to one, and only one, actor
Если же речь идёт о внутренней структуре модуля, то здесь работает разделение по аспектам реализации. И, кстати, в формулировке 2014 года Роберт Мартин уже убрал единственное число и говорит об изменениях по схожим причинам:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
В такой формулировке выделение слоя для работы с SQL полностью соответствует SRP: у кода для работы с БД действительно все причины изменений схожи.
Ну и наконец, Роберт Мартин прямо пишет в Clean Architecture, что принцип SRP надо соблюдать примерно на 90%.
Так что не надо обесценивать SRP, и тем более не надо заменять его на "практические рекомендации", весьма спорные и выходящие из моды за несколько лет.
И, кстати, actor и stakeholder - разные вещи, почему автор решил, что можно одно заменить на другое, не будучи при этом носителем английского языка?
Разница объясняется, например, здесь: http://fserranocs460.blogspot.com/2014/01/use-cases-actors-vs-stakeholders.html
Я не вижу противоречия разных формулировок, потому что разные формулировки говорят о разных уровнях.
Строго говоря, немного не так, но в целом да
The Single Responsibility Principle is about functions and classes—but it reappears in a different form at two more levels. At the level of components, it becomes the Common Closure Principle. At the architectural level, it becomes the Axis of Change responsible for the creation of Architectural Boundaries. We’ll be studying all of these ideas in the chapters to come.
Возможно Я не согласен с некоторыми пунктами, но статья великолепная, потому что проводит ревизию того, ПОЧЕМУ были изобретены принципы SOLID.
Знание боли, которую они хотели решить и развернутых интерпретаций и примеров использования - вот, чего часто не хватает в разборах.
Особенно это помогает от возведений в абсолют - больше интерфейсов богу интерфейсов (и каждый - по одному методу!), делай функции еще меньше, чтобы было невозможно понять, что они делают, не используй наследование никогда и т.д
Действительно, у каждого свой SRP.
И 4 пункта практических рекомендаций неплохи.
Я люблю GRASP по Крэгу Ларману, для меня гораздо понятнее и полезнее SOLID.
Мне кажется, уже на собеседованиях нет смысла про SOLID спрашивать, он захайпован, все кандидаты заучивают.
Многоликий принцип единственности ответственности
Принцып SRP самый простой и в тоже время самый сложный. Ошибка думать что он применим только к классу. Этот принцып применим вообще ко всему: сервис/программа, модуль, пакет, класс, метод, блок кода.
SRP+сервис = микросервисная архитектура
SRP+модуль = новые микро-модули (примеры: организация модулей в jackson, spring, etc)
SRP+код фильтрации коллекций = guava
p.s. как по мне это основа без которой сделать что-то более менее адекватное невозможно. (IMHO): все последующие принципы вытекают из данного (ISP — по факту говорит о SRP для интерфейсов), за редким исключением
Многоликий принцип единственности ответственности