Разница между принципом единой ответственности и разделением проблем

В чем разница между принципом единой ответственности и разделением проблем?

ОТВЕТЫ

Ответ 1

Единый принцип ответственности (СРП) - дать каждому классу только одну причину изменение; и "Причина изменения" == "обязанность". В примере: Счет-фактура класс не несет ответственности для печати. ​​

Разделение проблем (с 1974 года). Концерн == Особенность системы. принятие заботиться о каждой из проблем: для каждого одна проблема, другие проблемы не имеет значения. Скрытие реализации поведение.

Из здесь.

Ответ 2

Разделение принципа Concern vs Single Responsibility (SoC vs SRP)

Из связанной статьи:

Разделение проблем (SoC) - это процесс разбивки компьютерной программы на отдельные функции, которые как можно меньше перекрывают функциональность. Вызывает озабоченность любой интерес или фокус в программе. Как правило, проблемы являются синонимом функций или поведения. http://en.wikipedia.org/wiki/Separation_of_concerns

Принцип единой ответственности (SRP) - каждый объект должен иметь одну ответственность и что все его услуги должны быть узко согласованы с этой ответственностью. На некотором уровне Cohesion считается синонимом SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle

Ответ 3

По моему мнению, принцип единой ответственности - один из инструментов/идиом для достижения разделения проблем.

Ответ 4

Единая ответственность заявляет, что объект несет ответственность за единицу работы.

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

Аналогичные конечные результаты... несколько разных приложений.

Ответ 5

Принцип единой ответственности и разделение проблем - это одно и то же.

Конечно, вы можете увязнуть в академической дискуссии, пытаясь разобраться в какой-то разнице между ними, но почему? Во всех смыслах и целях они описывают одно и то же. Самая большая проблема заключается в том, что люди настолько увлечены тем, что хотят точно знать, что такое "забота" и "ответственность", что они, возможно, упускают важную идею позади SRP и SoC.

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

Это применяется на уровне модуля, например MVC является архитектурным шаблоном, продвигающим SRP и SoC. Кодовая база разделяется на изолированные модели, представления и контроллеры. Таким образом, изменение вида может быть сделано независимо от модели. Два двух не ужасно переплетаются.

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

Также даже на уровне метода разбивайте большие методы на более мелкие методы.

В принципе. SRP - это принцип, а не правило, поэтому вам не нужно (читай: не могу/не должен) следовать за ним до крайности. Это не значит, что зайти слишком далеко и иметь только один метод из семи строк в каждом классе, например. Это просто означает общий принцип разделения кода на отдельные части. Дело в том, что это приведет к лучшей кодовой базе и более стабильному программному обеспечению.

Ответ 6

Разделение проблем (SoC). Разделите приложение на отдельные функции с минимальным перекрытием функциональности. (Microsoft).

"Концерн" = "отдельная функция" = "отдельный раздел"

"Концерн" работает как на высоком, так и на низком уровне

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

"Ответственность" = "причина изменения" изменить что? "одна часть функциональности, предоставляемой программным обеспечением" = Основной блок

Заключение

  • Единый принцип ответственности работает с базовыми единицами → работает на низком уровне

  • Разделение проблем работает как на высоком, так и на низком уровне

  • SRP и SoC работают вместе для разделения проблем. Они
    точно так же на низком уровне

Ответ 7

Разделение проблем - это процесс; Принцип единой ответственности - это философия дизайна/архитектуры. Они не полностью не пересекаются, но они служат различным целям.

Ответ 8

Аналогично, но: SoC связан с опасениями: разбить сложную проблему на несколько проблем, SRP должен иметь только одну ответственность.

Ответ 9

SRP и SOC работают на разных уровнях абстракции. Цель в обоих случаях заключается в уменьшении сцепления и усилении сцепления. Хотя SRP работает больше на уровне объекта, SOC может также работать над реализацией уровня функции. Функция может быть реализована одним объектом, но также несколькими объектами. Поэтому связь и сплоченность обоих принципов могут различаться.

Ответ 10

Я попытался провести сравнение между разделением проблем (SoC) и принципом единой ответственности (SRP).

Различия

  • SRP находится на уровне класса, но SoC находится в каждой компьютерной программе, абстракции... или иногда архитектурном уровне.

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

  • Концепция SRP основана на сплоченности (высокой когезии), тогда как SoC близок к Молекулярности, делит и побеждает (D & C),... на каждом уровне абстракции.

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

Сходства

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

Ответ 11

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

Вдохновение Мартина для ПСП было получено от Дэвида Парнаса, Эдсгера Дейкстры (который придумал термин "Разделение проблем") и Ларри Константина (который придумал термины "Сочетание и сплоченность"). Мартин объединил свои идеи в ПСП.

Еще одна формулировка принципа единой ответственности:

Соберите вещи, которые меняются по тем же причинам. Отделите те вещи, которые меняются по разным причинам.

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

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

Что касается первоначального вопроса, небольшая разница между SRP и SoC заключается в том, что Мартин уточнил термин "проблемы", чтобы обозначить людей.

Ответ 12

Ответ:

Разделение проблем (SoC) - более универсальный термин - его можно применять на системном уровне или на более низких уровнях, таких как классы (или даже методы внутри класса).

Принцип единой ответственности (SRP) используется для обсуждения SoC на более низких уровнях, например, в классе

Способы подумать об этом:

  1. На низком уровне SoC и SRP являются синонимами. Таким образом, вы можете сказать, что SRP является избыточным термином или что SoC следует использовать только для обсуждения системного уровня.

  2. Учитывая (1), термин SoC несколько неоднозначен. Вам нужен контекст, чтобы знать, идет ли речь о SoC высокого уровня или SoC более низкого уровня

  3. Чтобы помнить, что SRP - это термин только для более низких уровней, подумайте об этом: в повседневном языке "ответственность" - это, как правило, четко определенная вещь, которая может быть привязана к конкретному коду, тогда как "проблемы" обычно являются неясными и могут охватывает множество связанных вещей, поэтому, возможно, именно поэтому SoC более естественно подходит для обсуждения системного уровня, чем SRP

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