Різниця між принципом єдиної відповідальності та розділенням проблем


Відповіді:


39

Принцип єдиної відповідальності (SRP) - дайте кожному класу лише одну причину для зміни; та “Причина зміни” == “відповідальність”. Наприклад: Клас рахунків-фактур не несе відповідальності надрукувати себе.

Поділ проблем (з 1974). Проблема == особливість системи. Турбота про кожну проблему: для кожної проблеми інші проблеми не мають значення. Приховування реалізації поведінки.

Від сюди .


В принципі те саме, але, схоже, SoC, здається, не перешкоджає надмірному розділенню. Надмірна роздільність не така погана, як перенапруження, але погана, оскільки підвищує вартість побудови та обслуговування програмного забезпечення (та ж проблема, що і перенапруга - різні причини). SoC вимагає двох дуже важливих факторів успіху, принаймні для кожного дядька боб (1) "проблеми" є на першому рівні бізнесу (а не технології); (2) Поділяти речі, які належать разом, є помилкою. blog.cleancoder.com/uncle-bob/2014/05/08/…
FastAl

17

На мою думку, Принцип єдиної відповідальності є одним із інструментів / ідіом досягнення розділення проблем.


3
Що? Можна легко створити програму, яка має функцію, що не перекривається (SRP), яка містить багато об’єктів, що стосуються не окремих (! SOC).
Ендрю Сонг

6
Але набагато важче зобразити об’єкт, який має багато обов’язків, і все ж дотримується принципу поділу проблем. Іншими словами, для досягнення реального розділення проблем (на всіх рівнях) краще дотримуватися принципу єдиної відповідальності
БостонЛоган,

17

Поділ занепокоєння проти принципу єдиної відповідальності (SoC проти SRP)

Зі зв’язаної статті:

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

Принцип єдиної відповідальності (SRP) - кожен об'єкт повинен нести єдину відповідальність, і всі його служби повинні бути узко узгодженими з цією відповідальністю. На деякому рівні згуртованість вважається синонімом СРП. http://en.wikipedia.org/wiki/Однозначний_принцип_відповідальності


4
з цим визначенням, на якому рівні згуртованість розглядається як синонім принципу єдиної відповідальності? Я шукав, що існує багато рівнів згуртованості (від низького до високого): збіговий, логічний, часовий, процедурний та функціональний .. у цьому поясненні це означає лише "функціональну згуртованість"?
limonik 02

13

Єдина відповідальність стверджує, що Об’єкт відповідає за одну одиницю роботи.

Розділення проблем стосується того, що додатки слід розділяти на модулі, функціональні можливості яких накладаються якомога менше.

Подібні кінцеві результати ... дещо інші програми.


у чому різниця між об’єктом та модулем? Для мене модуль - це клас, а об'єкт - це клас або екземпляр класу
Рукіан

Модуль може представляти собою цілу частину подібних функціональних можливостей програми, що складається з взаємодії між багатьма класами (кожен клас несе єдину відповідальність, якщо ви дотримуєтеся єдиної відповідальності).
Джастін Нісснер,

12

Принцип єдиної відповідальності та розділення турбот насправді одне і те ж.

Звичайно, ви можете заглибитися в академічній дискусії, намагаючись дратувати якусь різницю між ними, але чому? Для всіх цілей вони описують одне і те ж. Найбільша проблема полягає в тому, що люди настільки захоплюються бажанням точно знати, що таке "турбота" та "відповідальність", що, можливо, вони пропускають важливу ідею, що лежить в основі SRP та SoC.

Ця ідея полягає в тому, щоб просто розділити свою кодову базу на слабо пов'язані ізольовані частини. Це дозволяє декільком розробникам працювати над різними частинами, не впливаючи один на одного, а також дозволяє одному розробникові модифікувати одну ізольовану частину, не порушуючи іншу.

Це застосовується на рівні модуля, наприклад, MVC - це архітектурний шаблон, що просуває SRP та SoC. Кодова база розділена на окремі моделі, подання та контролери. Таким чином модифікація подання може бути здійснена незалежно від моделі. Двоє двох не жахливо переплетені.

На нижчому рівні це слід застосовувати і до занять. Замість того, щоб класти десятки методів в один клас, розділіть код на кілька. З тих самих причин.

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

В принципі. SRP - це принцип, а не правило, тому вам не потрібно (читати: не можна / не слід) дотримуватися його релігійно до крайності. Це не означає заходити занадто далеко і мати лише один метод із семи рядків у кожному класі, наприклад. Це просто означає загальний принцип розбиття коду на окремі частини. Справа в тому, що це призведе до кращої кодової бази та більш стабільного програмного забезпечення.


8

Поділ проблем (SoC). Розділіть свою програму на різні функції з якомога меншим накладанням функціональних можливостей. (Microsoft).

“Занепокоєння” = “відмінна риса” = “окремий розділ”

“Концерн” працює як на високому, так і на низькому рівнях

Принцип єдиної відповідальності  передбачає, що кожен модуль або клас повинен нести відповідальність за одну частину функціональних можливостей, що надаються програмним забезпеченням, і що відповідальність повинна бути повністю інкапсульована класом. Усі його служби повинні бути узко узгодженими з цією відповідальністю. (Визначення у Вікіпедії)

“Відповідальність” = “причина змінити” що змінити? “Одна частина функціональних можливостей, що надаються програмним забезпеченням” = Основна одиниця

Висновок

  • Принцип єдиної відповідальності працює на базових одиницях -> працює на низькому рівні

  • Поділ проблем стосується як високого, так і низького рівня

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


SRP також працює на різних рівнях. Ви маєте більш загальну відповідність на рівні бібліотеки, ніж на рівні класу та більш конкретну на рівні функцій.
Phil1970

7

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

Натхнення Мартіна для СРП черпали Девід Парнас, Едджер Дейкстра (який створив термін " Поділ турбот" ) і Ларрі Константин (який створив терміни " Зв'язування та згуртованість" ). Мартін об'єднав свої ідеї в СРП.

Іншим формулюванням принципу єдиної відповідальності є:

Зберіть разом речі, які змінюються з тих самих причин. Відокремте ті речі, які змінюються з різних причин.

Якщо ви задумаєтесь над цим, ви зрозумієте, що це лише ще один спосіб визначити згуртованість та взаємозв'язок. Ми хочемо збільшити згуртованість між речами, які змінюються з тих самих причин, і ми хочемо зменшити зв'язок між тими речами, які змінюються з різних причин.

Однак, думаючи про цей принцип, пам’ятайте, що причинами змін є люди . Це люди , які просять зміни. І ви не хочете заплутувати цих людей або себе, змішуючи разом код, який багатьом людям цікавий з різних причин.

Щодо вихідного питання, то незначна відмінність між SRP та SoC полягає в тому, що Мартін уточнив термін " стосується" для позначення людей .


3

Поділ проблем - це процес; Принцип єдиної відповідальності - це філософія дизайну / архітектури. Вони не повністю роз’єднані, але служать різним цілям.


2

Подібне, але: SoC пов'язаний з проблемами: щоб розбити складну проблему на кілька проблем, SRP має нести лише одну відповідальність.


2

SRP та SOC працюють на різному рівні абстракції. Мета в обох випадках - зменшити зв'язок і посилити згуртованість. Хоча SRP працює більше на об’єктному рівні, SOC може також працювати на реалізації функціонального рівня. Функція може бути реалізована як одним об'єктом, так і кількома об'єктами. Тому взаємозв'язок і згуртованість обох принципів можуть відрізнятися.


2

Я намагався провести порівняння між Поділом проблем (SoC) та Принципом єдиної відповідальності (SRP).

Відмінності

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

  • SRP стосується якості (як не чого) розподілу вашого домену на цілісні класи, на яких покладена одна відповідальність (одна причина змінити). З іншого боку, SoC є принципом проектування для розділення контексту на окремі розділи, таким чином, що кожен розділ вирішує окрему проблему (що не як), оскільки існує багато інструментів (наприклад, класи, функції, модулі, пакети,. ..) для досягнення цієї мети на різних рівнях.

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

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

Подібність

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

0

Відповідь:

Поділ проблем (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, який досягається на рівні методу, але потім порушується на рівні класу, перегляньте цю публікацію в блозі Артура Тросіна .


0

Поділ проблем

Принцип розділення турбот (SOC) говорить, що артефакт коду повинен дозволяти зосередити свою увагу на певному аспекті. Артефактом коду може бути що завгодно, починаючи від певної функції, закінчуючи класом, цілим пакетом або навіть цілим додатком. Принцип SOC може бути застосований до будь-якого архітектурного рівня у власних додатках. Прикладом архітектури, де застосовується SOC, є багатошарова архітектура.

Принцип єдиної відповідальності

Принцип єдиної відповідальності (SRP) говорить, що "модуль повинен мати одну і лише одну причину для зміни" (Clean Architecture, Martin, с. 62). SRP застосовується до рівня модуля, і при застосуванні SRP слід зосередитися на причині зміни.

Висновок

Принцип SOC говорить, що артефакт коду повинен дозволяти зосередити свою увагу на певному аспекті. SRP робить це конкретним, заявляючи, що на рівні модуля ми повинні зосередити свою увагу на причині змін. Таким чином, SRP є SOC.

PS Для повноти: Загальний принцип закриття

Загальний принцип закриття (CCP) - це перерахування SRP на ще вищому рівні - на рівні компонентів. КПК зазначає, що класи, які змінюються з тих самих причин і в той же час, повинні бути об'єднані в одні й ті ж компоненти (Clean Architecture, с. 105). КПК - ще один приклад SOC.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.