Как вы определяете, насколько крупной или детальной должна быть «ответственность» при использовании принципа единой ответственности?

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

Следующий текст впервые появился в выпуске Code Magazine за январь / февраль 2010 г. и доступен в Интернете по адресу " Разработка программного обеспечения SOLID, шаг за шагом "

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

Поначалу это может показаться нелогичным. Не было бы проще сказать, что у класса должна быть только одна причина для существования? На самом деле, ни одна причина для существования легко может быть доведена до крайности, которая принесет больше вреда, чем пользы. Если вы доведете его до такой крайности и создадите классы, у которых есть одна причина для существования, вы можете получить только один метод для каждого класса. Это привело бы к большому разрастанию классов даже для самых простых процессов, что сделало бы систему трудной для понимания и сложной для изменения.

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

Возьмем, к примеру, двигатель автомобиля. Вы заботитесь о внутренней работе двигателя? Вы заботитесь о том, чтобы у вас были поршень, распределительный вал, топливная форсунка и т. Д. Определенного размера? Или вас волнует только то, что двигатель работает должным образом, когда вы садитесь в машину? Ответ, конечно, полностью зависит от контекста, в котором вам нужно использовать движок.

Если вы механик, работающий в автомастерской, вы, вероятно, заботитесь о внутренней работе двигателя. Вам необходимо знать конкретную модель, различные размеры деталей и другие характеристики двигателя. Если у вас нет этой информации, вы, скорее всего, не сможете обслуживать двигатель должным образом. Однако, если вы обычный человек, которому нужен только транспорт из пункта А в пункт Б, вам, скорее всего, не понадобится такая информация. Понятие отдельных поршней, свечей зажигания, шкивов, ремней и т. Д. Для вас почти бессмысленно. Вам важно только, чтобы у вашего автомобиля был двигатель и он работал правильно.

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

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

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

Разница небольшая, но мне помогает. Давайте рассмотрим пример в wikipedia о механизме отчетов:

• если вероятность того, что содержимое и шаблон отчета изменится одновременно, высока, это может быть одним компонентом, поскольку они явно связаны. (Также может быть два)

• но если вероятность того, что содержимое изменится без шаблона, важна, тогда это должны быть два компонента, потому что они не связаны. (Было бы опасно иметь один)

Но я знаю, что это личная интерпретация SRP.

Еще мне нравится второй прием: «Опишите свой класс одним предложением». Обычно это помогает мне определить, есть четкая ответственность или нет.

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

Чтобы лучше понять это, вероятно, будет полезно четко различать, за что отвечает класс, и что делает метод. Метод должен «делать только одно» (например, складывать два числа, хотя для большинства целей «+» - это метод, который уже делает это), в то время как класс должен представлять единственную четкую «ответственность» своим потребителям. Это ответственность на гораздо более высоком уровне, чем метод.

У такого класса, как Repository, есть четкая и исключительная ответственность. Он имеет несколько методов, таких как Save и Load, но несет четкую ответственность за обеспечение поддержки сохраняемости для сущностей Person. Класс также может координировать и / или абстрагироваться от ответственности зависимых классов, снова представляя это как единую ответственность для других классов-потребителей.

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

Я использую простое эмпирическое правило: уровень или степень детализации ответственности должен соответствовать уровню или степени детализации рассматриваемой «сущности». Очевидно, что цель метода всегда будет более точной, чем цель класса, службы или компонента.

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

@Derick bailey: красивое объяснение
Некоторые дополнения:
Совершенно приемлемо, что применение SRP является контекстной базой.
Остается вопрос: есть ли какие-либо объективные способы определить, нарушает ли данный класс SRP?

Некоторые контексты проектирования довольно очевидны (например, пример автомобиля Дерика), но в остальном контексты, в которых должно быть определено поведение класса, во многих случаях остаются нечеткими.

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

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

Я применил этот подход, и он дал мне хорошие результаты.

Но мои поиски «объективных способов определения классовой ответственности» все еще продолжаются.

Я с уважением не согласен, когда Крис Никола выше говорит, что «класс должен нести единую четкую« ответственность »перед своими потребителями.

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

Для меня не очень понятно, что такое ответственность, и доказательством этого является количество вопросов, которые возникают в связи с этой концепцией.

"единственная причина измениться"

or

"если в описании есть слово" и "то его нужно разбить"

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

Для меня истинный SRP приводит к паттерну Фасад, где у вас есть класс, который просто делегирует вызовы другим классам.

Например:

class Modem
  send()
  receive()

Refactors to ==>

class ModemSender
class ModelReceiver

+

class Modem
  send() -> ModemSender.send()
  receive()  -> ModemReceiver.receive()

Мнения приветствуются