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

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

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

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


design-patterns design-guidelines single-responsibility-principle
person archie    schedule 09.12.2009    source источник
comment
См. Этот вопрос и ответ: stackoverflow.com/questions/2455705/   -  person User    schedule 23.07.2011

Ответы (4)


arrow_upward
2
arrow_downward

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

person Ned Batchelder    schedule 09.12.2009

arrow_upward
1
arrow_downward

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

person MattMcKnight    schedule 09.12.2009
comment
В этом случае не задействован уровень представления (который находится за пределами этой подсистемы), однако он объединяет обработку данных и хранение метаданных, полученных в результате обработки. Я считаю, что это связано с контекстом / системой отсчета. На более низких уровнях внутри этой подсистемы, безусловно, применяется SRP, но там, где SRP кажется абсурдным, это когда эти компоненты никогда не связываются вместе в единое целое более высокого уровня, пока не будет достигнут верхний уровень всей системы. - person archie; 09.12.2009
comment
Я не уверен, что это отличная аналогия, но внутри мозга я вижу, что отдельные клетки мозга несут единую ответственность и что группы соседних ячеек объединены в единицы более высокого уровня, у которых есть другие единственные, но более высокие уровни ответственности, и что это построение на единицах более низкого уровня продолжается до тех пор, пока у вас не будет полноценного мозга. SRP-абсордий, который, как мне кажется, сейчас имеет плоскую структуру мозга, связывает миллиарды клеток вместе в одну кучу спагетти. Может быть, это то, чем станет SRP, если зайти слишком далеко ... спагетти-бизнес-логика ...? - person archie; 09.12.2009

arrow_upward
0
arrow_downward

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

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

person Tom Dalling    schedule 10.12.2009

arrow_upward
0
arrow_downward

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

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

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

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

person Henk van Dijken    schedule 12.12.2009