На каком уровне абстракции принцип Single Responsibility (SRP) больше не имеет смысла?

Question

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

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

В моем конкретном случае служба, которая «обрабатывает foos, сохраняет свои результаты и обеспечивает доступ к этим результатам», в моей голове несет единственную ответственность «подсистемы обработки foo», однако коллега не согласен и видит это как 2-3 отдельные обязанности. Мое дело в том, что если вы всегда разбиваете отдельные обязанности на мелкие детали, то наличие «банка» является нарушением СРП, поскольку оно «держит деньги, ведет счета, продает ипотечные кредиты ...».

Answer 1

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

Answer 2

Я думаю, что вы, вероятно, правы, но не можете использовать этот принцип для разрешения вашего спора. Роберт Мартин определяет ответственность как «причину изменения». Если структура изменений foo (например, поле добавляется), вы хотите, чтобы изменения отражались в этом классе. В подходе вашего коллеги все классы должны были измениться. Здесь принцип должен применяться в контексте прикладного уровня, поскольку он также изменит отображаемый код, который, очевидно, не должен находиться в одном классе. Если механизм хранения изменится (например, с использованием другого драйвера базы данных), я бы ожидал, что это будет обработано извне, с помощью конфигурации настойчивости, поэтому просто оставляйте другие причины для изменения своего класса, и каждый может быть счастлив.

Answer 3

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

Что касается примера банка, который вы дали, я бы сказал, что банк не продавать ипотечные кредиты. Департамент кредитов (или что-то еще) продает ипотечные кредиты, а банк имеет отдел кредитов. Рассмотрение «банка» как единого объекта является эквивалентом одного человека, управляющего всем банком.

Answer 4

Я не согласен с вашим коллегой.

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

Что касается примера банка, его единственная ответственность будет предоставлять финансовые услуги.

Эта концепция работает как структура пробоя работы. Когда вы спускаетесь и «видите» коллекцию отделов, у них будет своя собственная ответственность. Таким образом, ответственность также может быть нарушена. Важно то, что разбивка выровнена.