Разница между принципом единой ответственности и разделением интересов
В чем разница между принципом единой ответственности и разделением интересов?
10 ответов
Принцип единой ответственности (SRP)- дать каждому классу только одну причину для изменения; и "Причина изменения" == "ответственность". Например: класс Invoice не несет ответственности за самопечатание.
Разделение концернов (с 1974 года). Обеспокоенность == особенность системы. Забота о каждой из проблем: для каждой проблемы другие проблемы не имеют значения. Скрытие реализации поведения.
Принцип единой ответственности и разделение интересов - это одно и то же.
Конечно, вы можете увязнуть в академической дискуссии, пытаясь выявить какую-то разницу между ними, но почему? Для всех намерений и целей они описывают одно и то же. Самая большая проблема заключается в том, что люди настолько увлечены желанием точно знать, что такое "озабоченность" и "ответственность", что, возможно, они упускают важную идею, лежащую в основе SRP и SoC.
Эта идея состоит в том, чтобы просто разбить вашу кодовую базу на слабо связанные изолированные части. Это позволяет нескольким разработчикам работать над разными частями, не влияя друг на друга, а также позволяет одному разработчику изменять одну изолированную часть, не нарушая другую.
Это применяется на уровне модулей, например, MVC является архитектурным шаблоном, продвигающим SRP и SoC. Кодовая база разбита на изолированные модели, представления и контроллеры. Таким образом, изменение представления может быть выполнено независимо от модели. Два два ужасно не переплетаются.
На более низком уровне это должно быть применено и к классам. Вместо того, чтобы помещать десятки методов в один класс, разбейте код на несколько. По тем же причинам.
Также даже на уровне методов разбейте большие методы на более мелкие.
В принципе. SRP - это принцип, а не правило, поэтому вы не должны (читай: не можете / не должны) строго придерживаться его. Это не означает, что нужно заходить слишком далеко и иметь только один метод из семи строк в каждом классе, например. Это просто означает общий принцип разделения кода на отдельные части. Дело в том, что это приведет к лучшей кодовой базе и более стабильному программному обеспечению.
Разделение интересов и принципа единой ответственности ( SoC против SRP)
Из связанной статьи:
Разделение проблем (SoC) - это процесс разделения компьютерной программы на отдельные функции, которые как можно меньше пересекаются в функциональности. Беспокойство - это любой интерес или акцент в программе. Как правило, проблемы являются синонимами функций или поведения. http://en.wikipedia.org/wiki/Separation_of_concerns
Принцип единой ответственности (SRP) - каждый объект должен нести единую ответственность, и что все его услуги должны быть тесно связаны с этой ответственностью. На некотором уровне сплоченность рассматривается как синоним SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle
По моему мнению, принцип единой ответственности является одним из инструментов / идиом для достижения разделения проблем.
Поскольку ни один из предыдущих ответов не цитирует Роберта Мартина, который создал Принцип единой ответственности, я думаю, что здесь нужен более авторитетный ответ.
Вдохновение Мартина для SRP было взято из Дэвида Парнаса, Эдсгера Дейкстры (который придумал термин " Разделение проблем") и Ларри Константина (который придумал термины " Соединение и сплоченность"). Мартин объединил свои идеи в ПСП.
Еще одна формулировка принципа единой ответственности:
Соберите вещи, которые меняются по тем же причинам. Отделите те вещи, которые меняются по разным причинам.
Если вы подумаете об этом, вы поймете, что это просто еще один способ определения сплоченности и сцепления. Мы хотим повысить сплоченность между вещами, которые меняются по одним и тем же причинам, и мы хотим уменьшить связь между этими вещами, которые меняются по разным причинам.
Однако, когда вы думаете об этом принципе, помните, что причинами перемен являются люди. Это люди, которые требуют изменений. И вы не хотите сбивать с толку этих людей или себя, смешивая код, который заботится о разных людях по разным причинам.
Что касается первоначального вопроса, небольшая разница между SRP и SoC заключается в том, что Мартин уточнил термин " проблемы", чтобы обозначить людей.
Одиночная ответственность гласит, что Объект отвечает за одну единицу работы.
Разделение проблем гласит, что приложения должны быть разбиты на модули, функциональные возможности которых перекрываются как можно меньше.
Аналогичные конечные результаты... немного разные приложения.
Разделение концернов (SoC). Разделите ваше приложение на отдельные функции с минимальным дублированием функций. (Microsoft).
"Концерн" = "отличительный признак" = "отдельный раздел"
"Концерн" работает как на высоком, так и на низком уровне
Принцип единой ответственности гласит, что каждый модуль или класс должен нести ответственность за одну часть функциональных возможностей, предоставляемых программным обеспечением, и эта ответственность должна быть полностью заключена в класс. Все его услуги должны быть тесно связаны с этой ответственностью. (Определение из Википедии)
"Ответственность" = "причина для изменения" изменить что? "Отдельная часть функциональности, предоставляемой программным обеспечением" = Базовая единица
Заключение
Принцип единой ответственности работает на базовых единицах -> работает на низком уровне
Разделение концернов работает как на высоком, так и на низком уровнях.
SRP и SoC работают вместе для разделения проблем. Они есть
точно так же на низком уровне
Разделение проблем - это процесс; Принцип единой ответственности - это философия дизайна / архитектуры. Они не полностью разделены, но служат разным целям.
Я попытался провести сравнение между разделением интересов (SoC) и принципом единой ответственности (SRP).
Различия
SRP находится на уровне класса, но SoC есть в каждой компьютерной программе, абстракции... или иногда на архитектурном уровне.
SRP касается качества (как не чего) деления вашего домена на сплоченные классы, которые несут только одну ответственность (одна причина для изменения). С другой стороны, SoC является принципом проектирования для разделения контекста на отдельные разделы, так что каждый раздел посвящен отдельной проблеме (что не так, как), так как существует множество инструментов (например, классы, функции, модули, пакеты,)...) чтобы достичь этой цели на разных уровнях.
Концепция SRP основана на сплоченности (высокая сплоченность), тогда как SoC близка к Молекулярности, разделяй и властвуй (D&C), ... на каждом уровне абстракции.
SoC - это хороший принцип проектирования для управления сложностью, такой как абстракция, тогда как для достижения отдельных ответственных классов вы можете использовать принцип SoC как отличное решение. Таким образом, способ узнать, что класс имеет более чем одну ответственность, - это если вы можете извлечь другую ответственность (озабоченность) из этого класса.
сходства
- После применения каждого из этих принципов ваш контекст становится более пригодным для повторного использования, поддерживаемым, надежным, читаемым,....
SRP и SOC работают на разном уровне абстракции. Цель в обоих случаях уменьшить сцепление и усилить сцепление. В то время как SRP больше работает на уровне объектов, SOC также может работать на уровне реализации функций. Функция может быть реализована как одним объектом, так и несколькими объектами. Поэтому связь и согласованность обоих принципов могут различаться.
Аналогично, но: SoC связан с проблемами: чтобы разбить сложную проблему на несколько проблем, SRP должен нести только одну ответственность.
Ответ:
Разделение проблем (SoC) - более универсальный термин - его можно применять на системном уровне или на более низких уровнях, таких как классы (или даже методы внутри класса).
Принцип единой ответственности (SRP) используется для обсуждения SoC на более низких уровнях, например, в классе
Способы подумать об этом:
На низком уровне SoC и SRP являются синонимами. Таким образом, вы можете сказать, что SRP является избыточным термином или что SoC следует использовать только для обсуждения системного уровня.
Учитывая (1), термин SoC несколько неоднозначен. Вам нужен контекст, чтобы знать, идет ли речь о SoC высокого уровня или SoC более низкого уровня
Чтобы помнить, что SRP - это термин только для более низких уровней, подумайте об этом: в повседневном языке "ответственность" - это, как правило, четко определенная вещь, которая может быть привязана к конкретному коду, тогда как "проблемы" обычно являются неясными и могут охватывает множество связанных вещей, поэтому, возможно, именно поэтому SoC более естественно подходит для обсуждения системного уровня, чем SRP
SoC в некотором смысле является более строгим требованием / принципом, чем SRP, потому что он применяется на системном уровне, и для того, чтобы быть действительно достигнутым на системном уровне, его также следует использовать при разработке компонентов системы. То есть высокий уровень SoC подразумевает достойный SoC/SRP на более низких уровнях - но обратное неверно, то есть более низкий уровень SoC/SRP не подразумевает SoC или что-либо еще для следующего более высокого уровня, не говоря уже о охватывающая система. Пример SoC/SRP, который достигается на уровне метода, но затем нарушается на уровне класса, можно найти в этом блоге Артура Тросина.
Разделение проблем
Принцип разделения проблем (SOC) гласит, что артефакт кода должен позволять сосредоточить внимание на определенном аспекте. Артефактом кода может быть что угодно: от конкретной функции до класса, целого пакета или даже всего приложения. Принцип SOC может применяться к любому архитектурному уровню в ваших приложениях. Примером архитектуры, в которой применяется SOC, является многоуровневая архитектура.
Принцип единой ответственности
Принцип единой ответственности (SRP) гласит, что "у модуля должна быть одна и только одна причина для изменения" (Clean Architecture, Martin, p. 62). SRP применяется на уровне модуля, и при применении SRP следует сосредоточиться на причине изменения.
Вывод
Принцип SOC гласит, что артефакт кода должен позволять сосредоточить внимание на определенном аспекте. SRP конкретизирует это, заявляя, что на уровне модуля мы должны сосредоточить внимание на причине изменения. Таким образом, SRP - это SOC.
PS Для полноты: Общий принцип закрытия
Общий принцип закрытия (CCP) - это повторение SRP на еще более высоком уровне, на уровне компонентов. CCP утверждает, что классы, которые изменяются по одним и тем же причинам и в одно и то же время, должны быть собраны в одни и те же компоненты (Чистая архитектура, стр. 105). КПК - еще один пример SOC.