У чому різниця між принципом єдиної відповідальності та розділенням проблем?
Відповіді:
Принцип єдиної відповідальності (SRP) - дайте кожному класу лише одну причину для зміни; та “Причина зміни” == “відповідальність”. Наприклад: Клас рахунків-фактур не несе відповідальності надрукувати себе.
Поділ проблем (з 1974). Проблема == особливість системи. Турбота про кожну проблему: для кожної проблеми інші проблеми не мають значення. Приховування реалізації поведінки.
Від сюди .
На мою думку, Принцип єдиної відповідальності є одним із інструментів / ідіом досягнення розділення проблем.
Поділ занепокоєння проти принципу єдиної відповідальності (SoC проти SRP)
Зі зв’язаної статті:
Розділення проблем (SoC) - це процес розбиття комп’ютерної програми на окремі функції, які якомога менше перекривають функціональність. Викликає занепокоєння будь-який предмет, що цікавить або зосереджується на програмі. Як правило, проблеми є синонімом особливостей або поведінки. http://en.wikipedia.org/wiki/Separation_of_concerns
Принцип єдиної відповідальності (SRP) - кожен об'єкт повинен нести єдину відповідальність, і всі його служби повинні бути узко узгодженими з цією відповідальністю. На деякому рівні згуртованість вважається синонімом СРП. http://en.wikipedia.org/wiki/Однозначний_принцип_відповідальності
Єдина відповідальність стверджує, що Об’єкт відповідає за одну одиницю роботи.
Розділення проблем стосується того, що додатки слід розділяти на модулі, функціональні можливості яких накладаються якомога менше.
Подібні кінцеві результати ... дещо інші програми.
Принцип єдиної відповідальності та розділення турбот насправді одне і те ж.
Звичайно, ви можете заглибитися в академічній дискусії, намагаючись дратувати якусь різницю між ними, але чому? Для всіх цілей вони описують одне і те ж. Найбільша проблема полягає в тому, що люди настільки захоплюються бажанням точно знати, що таке "турбота" та "відповідальність", що, можливо, вони пропускають важливу ідею, що лежить в основі SRP та SoC.
Ця ідея полягає в тому, щоб просто розділити свою кодову базу на слабо пов'язані ізольовані частини. Це дозволяє декільком розробникам працювати над різними частинами, не впливаючи один на одного, а також дозволяє одному розробникові модифікувати одну ізольовану частину, не порушуючи іншу.
Це застосовується на рівні модуля, наприклад, MVC - це архітектурний шаблон, що просуває SRP та SoC. Кодова база розділена на окремі моделі, подання та контролери. Таким чином модифікація подання може бути здійснена незалежно від моделі. Двоє двох не жахливо переплетені.
На нижчому рівні це слід застосовувати і до занять. Замість того, щоб класти десятки методів в один клас, розділіть код на кілька. З тих самих причин.
Також навіть на рівні методу розділіть великі методи на менші.
В принципі. SRP - це принцип, а не правило, тому вам не потрібно (читати: не можна / не слід) дотримуватися його релігійно до крайності. Це не означає заходити занадто далеко і мати лише один метод із семи рядків у кожному класі, наприклад. Це просто означає загальний принцип розбиття коду на окремі частини. Справа в тому, що це призведе до кращої кодової бази та більш стабільного програмного забезпечення.
Поділ проблем (SoC). Розділіть свою програму на різні функції з якомога меншим накладанням функціональних можливостей. (Microsoft).
“Занепокоєння” = “відмінна риса” = “окремий розділ”
“Концерн” працює як на високому, так і на низькому рівнях
Принцип єдиної відповідальності передбачає, що кожен модуль або клас повинен нести відповідальність за одну частину функціональних можливостей, що надаються програмним забезпеченням, і що відповідальність повинна бути повністю інкапсульована класом. Усі його служби повинні бути узко узгодженими з цією відповідальністю. (Визначення у Вікіпедії)
“Відповідальність” = “причина змінити” що змінити? “Одна частина функціональних можливостей, що надаються програмним забезпеченням” = Основна одиниця
Висновок
Принцип єдиної відповідальності працює на базових одиницях -> працює на низькому рівні
Поділ проблем стосується як високого, так і низького рівня
SRP та SoC спільно працюють над розмежуванням проблем. Вони
абсолютно однакові на низькому рівні
Оскільки жодна з попередніх відповідей не цитує Роберта Мартіна, який створив Принцип єдиної відповідальності , я думаю, що тут потрібна більш авторитетна відповідь.
Натхнення Мартіна для СРП черпали Девід Парнас, Едджер Дейкстра (який створив термін " Поділ турбот" ) і Ларрі Константин (який створив терміни " Зв'язування та згуртованість" ). Мартін об'єднав свої ідеї в СРП.
Іншим формулюванням принципу єдиної відповідальності є:
Зберіть разом речі, які змінюються з тих самих причин. Відокремте ті речі, які змінюються з різних причин.
Якщо ви задумаєтесь над цим, ви зрозумієте, що це лише ще один спосіб визначити згуртованість та взаємозв'язок. Ми хочемо збільшити згуртованість між речами, які змінюються з тих самих причин, і ми хочемо зменшити зв'язок між тими речами, які змінюються з різних причин.
Однак, думаючи про цей принцип, пам’ятайте, що причинами змін є люди . Це люди , які просять зміни. І ви не хочете заплутувати цих людей або себе, змішуючи разом код, який багатьом людям цікавий з різних причин.
Щодо вихідного питання, то незначна відмінність між SRP та SoC полягає в тому, що Мартін уточнив термін " стосується" для позначення людей .
SRP та SOC працюють на різному рівні абстракції. Мета в обох випадках - зменшити зв'язок і посилити згуртованість. Хоча SRP працює більше на об’єктному рівні, SOC може також працювати на реалізації функціонального рівня. Функція може бути реалізована як одним об'єктом, так і кількома об'єктами. Тому взаємозв'язок і згуртованість обох принципів можуть відрізнятися.
Я намагався провести порівняння між Поділом проблем (SoC) та Принципом єдиної відповідальності (SRP).
Відмінності
SRP знаходиться на рівні класу, але SoC є в кожній комп'ютерній програмі, абстракції ... або інколи архітектурному рівні.
SRP стосується якості (як не чого) розподілу вашого домену на цілісні класи, на яких покладена одна відповідальність (одна причина змінити). З іншого боку, SoC є принципом проектування для розділення контексту на окремі розділи, таким чином, що кожен розділ вирішує окрему проблему (що не як), оскільки існує багато інструментів (наприклад, класи, функції, модулі, пакети,. ..) для досягнення цієї мети на різних рівнях.
Концепція SRP базується на згуртованості (висока згуртованість), тоді як SoC наближається до молекулярності, розділяй і перемагай (D&C), ... на кожному рівні абстракції.
SoC - це хороший принцип дизайну для подолання складності, такий як абстракція, тоді як для досягнення окремих відповідальних класів ви можете використовувати принцип SoC як чудове рішення. Окрім того, спосіб дізнатися, що клас несе більше ніж одну відповідальність, полягає в тому, якщо ви можете вилучити з цього класу іншу відповідальність (занепокоєння).
Подібність
Відповідь:
Поділ проблем (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, с. 62). SRP застосовується до рівня модуля, і при застосуванні SRP слід зосередитися на причині зміни.
Висновок
Принцип SOC говорить, що артефакт коду повинен дозволяти зосередити свою увагу на певному аспекті. SRP робить це конкретним, заявляючи, що на рівні модуля ми повинні зосередити свою увагу на причині змін. Таким чином, SRP є SOC.
PS Для повноти: Загальний принцип закриття
Загальний принцип закриття (CCP) - це перерахування SRP на ще вищому рівні - на рівні компонентів. КПК зазначає, що класи, які змінюються з тих самих причин і в той же час, повинні бути об'єднані в одні й ті ж компоненти (Clean Architecture, с. 105). КПК - ще один приклад SOC.