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

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

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

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

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

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

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

Разница тонкая, но она мне помогает. Давайте рассмотрим пример на Википедии О механизме отчетности:

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

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

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

Кроме того, второй прием, который мне нравится: "опишите свой класс в одном предложении". Обычно это помогает мне идентифицировать себя. если есть четкая ответственность или нет.

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

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

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

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

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

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

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

Но мой поиск искать " объективные способы определение классовой ответственности " все еще продолжается.

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

Я думаю, что SRP - это хороший дизайн внутри класса, а не клиенты класса. Для меня не очень ясно, что такое ответственность, и доказательство-это количество вопросов, которые возникают у этой концепции.

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

Или

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

Приводит к вопросу: Где предел? В конце концов, любой класс с 2 открытыми методами имеет 2 причины для изменения, не так ли?

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

Например:

class Modem
  send()
  receive()

Refactors to ==>

class ModemSender
class ModelReceiver

+

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

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