Как Вы определяете, насколько крупный или мелкомодульный 'ответственность' должна быть при использовании единственного принципа ответственности?
В SRP 'ответственность' обычно описывается как 'причина измениться', так, чтобы каждый класс (или объект?) должен иметь только одну причину, кому-то придется пойти туда и изменить ее.
Но если Вы берете это к экстремальному мелкому модулю, Вы могли бы сказать, что объект, добавляющий два числа вместе, является ответственностью и возможной причиной для изменения. Поэтому объект не должен содержать никакую другую логику, потому что это произвело бы другую причину изменения.
Мне любопытно, если существует кто-либо там, который имеет какие-либо стратегии 'обзора', принцип единственной ответственности, это немного менее объективно?
4 ответа
, это сводится к контексту того, что вы моделируем. Я подробно писал и представлял принципы SOLID, и я специально обращаюсь к вашему вопросу в своих обсуждениях единой ответственности.
Следующее впервые появилось в выпуске журнала Code Magazine за январь / февраль 2010 г. и доступно в Интернете по адресу «Разработка программного обеспечения SOLID, шаг за шагом»
Принцип единой ответственности гласит что у класса должна быть одна и только одна причина для изменения.
Сначала это может показаться нелогичным. Не было бы проще сказать , что у класса должна быть только одна причина для существования? На самом деле, ни одна причина для существования может быть очень легко доведена до крайности, которая принесет больше вреда, чем пользы.Если вы доведете его до этой крайности и создадите классы, которые имеют одну причину для существования, вы можете закончить только одним методом для каждого класса. Это будет вызывает большое разрастание классов даже для самых простых из процессов, в результате чего система становится трудной для понимания и для изменения.
Причина, по которой у класса должна быть одна причина для изменения вместо одной причины для существования, - это бизнес контекст, в котором вы создаете {{1} }} система. Даже если две концепции логически различны, бизнес-контекст, в котором они нужны, может потребовать, чтобы они стали одним и тем же . Ключевой момент при принятии решения о том, когда класс должен измениться, основан не на чисто логическом разделении понятий , а на восприятии концепции бизнесом . Когда восприятие бизнеса и контекст изменились, тогда у вас есть причина изменить класс . Чтобы понять, какие обязанности должен выполнять один класс, вам нужно сначала понять , какую концепцию должен инкапсулировать этот класс и где вы ожидаете {{ 1}} детали реализации этой концепции , чтобы изменить.
Рассмотрим двигатель в автомобиле, например . Вы заботитесь о внутренней работе двигателя? Вы заботитесь о том, что у вас есть поршень определенного размера, распределительный вал, топливная форсунка и т. Д.? Или вас волнует только то, что двигатель работает как ожидается, когда вы сядете в машину? Ответ, конечно, полностью зависит от контекста в , который вам нужен для использования движка.
Если вы механик, работающий в автомастерской , вас, вероятно, волнует внутренняя работа двигателя.Вам необходимо знать конкретную модель, различные размеры деталей и другие характеристики двигателя. Если у вас нет этой информации, вы, скорее всего, не сможете обслуживать двигатель надлежащим образом. Однако, если вы обычный человек, которому нужен только транспорт из пункта A в пункт B, вам, скорее всего, не понадобится уровень информации. Понятие отдельных поршней, свечей зажигания, шкивов, ремней и т. Д. Почти бессмысленно для вас. Вам важно только, чтобы у вашего автомобиля был двигатель и он работал правильно.
Пример движка ведет прямо к сердцу принципа единой ответственности . Контексты вождения автомобиля и обслуживания двигателя дают два разных представления о том, что должно и не должно быть единой концепцией - причиной для изменений . В контексте обслуживания двигателя каждая отдельная часть должна быть отдельной. Вам необходимо закодировать их как отдельные классы и убедиться, что все они соответствуют своим индивидуальным спецификациям. Однако в контексте вождения автомобиля двигатель - это единое понятие, которое не нужно разбирать дальше. В этом случае у вас, вероятно, будет один класс с именем Engine. В любом случае контекст определил, каково соответствующее разделение обязанностей.
Я не считаю выполнение такой задачи, как сложение двух чисел, обязанностью. Обязанности бывают разных форм и размеров, но их, безусловно, следует рассматривать как нечто большее, чем выполнение одной функции.
Чтобы лучше понять это, вероятно, полезно четко различать, за что отвечает класс, и что делает метод. Метод должен «делать только одно» (например, складывать два числа, хотя для большинства целей «+» - это метод, который уже делает это), в то время как класс должен представлять единственную четкую «ответственность» своим потребителям. Это ответственность на гораздо более высоком уровне, чем метод.
Такой класс, как Repository, несет четкую и исключительную ответственность. Он имеет несколько методов, таких как Save и Load, но несет четкую ответственность за обеспечение поддержки сохраняемости для сущностей Person. Класс также может координировать и / или абстрагироваться от ответственности зависимых классов, снова представляя это как единую ответственность для других классов-потребителей.
Суть в том, что если применение SRP приводит к классам с одним методом, вся цель которых, кажется, просто заключить функциональность этого метода в класс, тогда SRP не применяется правильно.
Простое практическое правило I использование заключается в том, что уровень или степень детализации ответственности должен соответствовать уровню или степени детализации рассматриваемой «сущности». Очевидно, что цель метода всегда будет более точной, чем цель класса, службы или компонента.
Хорошей стратегией для оценки уровня ответственности может быть использование соответствующей метафоры. Если вы можете связать то, что вы делаете, с чем-то, что существует в реальном мире, это может помочь вам по-другому взглянуть на проблему, которую вы пытаетесь решить, включая возможность определить соответствующие уровни абстракции и ответственности.
Я склонен думать в терминах «скорости изменения» бизнес-требований, а не «причины для изменения».
Вопрос действительно в том, насколько вероятно, что вещи изменятся вместе , а не в том, могут ли они измениться или нет.
Разница небольшая, но мне помогает. Давайте рассмотрим пример в википедии о механизме отчетов:
если вероятность того, что содержание и шаблон отчета изменится одновременно, высока, она может быть одной компонент, потому что они очевидно связаны. (Также может быть два)
, но если вероятность того, что содержимое изменяется без шаблона, важна, тогда это должно быть двумя компонентами, потому что они не связаны между собой. (Было бы опасно иметь один)
Но я знаю, что это личная интерпретация SRP.
Также мне нравится второй прием: «Опишите свой класс одним предложением». Обычно это помогает мне определить, есть четкая ответственность или нет.