Переконайтесь, що кожен клас несе лише одну відповідальність, чому?

Відповідно до документації Microsoft, статті статті Wikipedia SOLID або більшості ІТ-архітекторів, ми повинні гарантувати, що кожен клас несе лише одну відповідальність. Мені хотілося б знати, чому, якщо всі, здається, згодні з цим правилом, схоже, ніхто не погоджується з причинами цього правила.

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

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

SRP так само застосовно до функцій, як і для класів, але основні мови OOP відносно погані при склеюванні функцій.

Краще обслуговування, легке тестування, швидше виправлення помилок - це лише (дуже приємні) результати застосування SRP. Основна причина (як зазначає Роберт К. Матін):

Клас повинен мати одну, і лише одну, причину для зміни.

Іншими словами, SRP піднімає зміни місцевості .

SRP також просуває DRY-код. Поки у нас є класи, які несуть лише одну відповідальність, ми можемо вирішити використовувати їх у будь-якому місці. Якщо у нас є клас, який має два обов'язки, але нам потрібен лише один з них, а другий заважає, у нас є два варіанти:

1. Скопіюйте та вставте клас в інший і, можливо, навіть створіть іншого мутанта з багатовідповідальністю (трохи підняти технічну заборгованість).
2. Розділіть клас і зробіть його таким, яким він повинен бути, в першу чергу, що може бути дорогим через велике використання оригінального класу.

Легко створити код для вирішення певної проблеми. Складніше створити код, який вирішує цю проблему, дозволяючи в подальшому безпечно вносити зміни. SOLID пропонує набір практик, які покращують код.

Щодо правильного: усі три. Всі вони переваги використання одноосібної відповідальності та причина, що ви повинні ним скористатися.

Що вони означають:

• Краще обслуговування означає, що його легше змінити і не змінювати так часто. Оскільки код менше, і цей код орієнтований на щось конкретне, якщо вам потрібно змінити щось, що не пов'язане з класом, клас не потрібно змінювати. Крім того, коли вам потрібно змінити клас, до тих пір, поки вам не потрібно буде змінювати загальнодоступний інтерфейс, вам потрібно лише турбуватися про цей клас і нічого іншого.
• Просте тестування означає менше тестів, менше налаштування. У класі не так багато рухомих частин, тому кількість можливих відмов у класі менша, а тому менше випадків, які потрібно перевірити. Буде менше приватних полів / членів для налаштування.
• Через два вище ви отримуєте клас, який менше змінюється і менше виходить з ладу, а отже, є більш надійним.

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

Ви робите те саме для кожного класу, і закінчуєте більше класів, які відповідають SRP. Це робить структуру складнішою з точки зору зв’язків, але простота кожного класу її виправдовує.

Ось аргументи, які, на мою думку, підтверджують твердження про те, що Принцип єдиної відповідальності є хорошою практикою. Я також надаю посилання на подальшу літературу, де ви можете прочитати навіть більш детальні міркування - і красномовніші, ніж мої:

• Краще обслуговування : в ідеалі щоразу, коли функціональність системи повинна змінюватися, буде один і лише один клас, який потрібно змінити. Чітке відображення між класами та обов'язками означає, що будь-який розробник, який бере участь у проекті, може визначити, для кого це клас. (Як зазначав @ MaciejChałapuk, див. Роберт К. Мартін, "Чистий код" .)

• Простіше тестування : в ідеалі класи повинні мати якомога менший публічний інтерфейс, а тести повинні стосуватися лише цього публічного інтерфейсу. Якщо ви не можете перевірити чітко, оскільки багато частин вашого класу є приватними, то це явна ознака того, що ваш клас має занадто багато обов'язків, і що ви повинні розділити його на менші підкласи. Зверніть увагу, це стосується також мов, де немає членів класу "загальнодоступні" чи "приватні"; наявність невеликого публічного інтерфейсу означає, що клієнтському коду дуже зрозуміло, які частини класу він повинен використовувати. (Див. Кент Бек, "Тестова розробка" для отримання більш детальної інформації.)

• Надійний код : ваш код не вийде з ладу більш-менш часто, тому що він добре написаний; але, як і всі коди, його кінцева мета - не спілкуватися з машиною , а з іншими розробниками (див. Кент Бек, "Шаблони впровадження" , глава 1.) Простіше зрозуміти чітку базу коду, тому буде введено менше помилок , і між виявленням помилки та її виправленням пройде менше часу.

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

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

З психологічної точки зору ви можете відстежувати лише кілька речей одночасно. Загальні оцінки - сім плюс-мінус два. Якщо клас робить кілька речей, вам потрібно відслідковувати їх усі одночасно. Це знижує вашу можливість відстежувати, що ви робите. Якщо клас робить три речі, і ви хочете лише одну з них, ви можете вичерпати свої можливості відслідковувати речі, перш ніж ви дійсно щось робите з класом.

Виконання кількох речей збільшує складність коду. Крім найпростішого коду, підвищення складності збільшує ймовірність появи помилок. З цієї точки зору ви хочете, щоб заняття були максимально простими.

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

Тому що програмне забезпечення органічне. Вимоги постійно змінюються, тому вам доведеться маніпулювати компонентами якомога менше головного болю. Не дотримуючись принципів SOLID, ви можете отримати базу коду, встановлену в конкреті.

Уявіть собі будинок із несучою бетонною стіною. Що відбувається, коли ви виймаєте цю стіну без будь-якої підтримки? Будинок, мабуть, обвалиться. У програмному забезпеченні ми цього не хочемо, тому ми структуруємо програми таким чином, щоб ви могли легко переміщувати / замінювати / змінювати компоненти, не завдаючи великої шкоди.

Я дотримуюся за цю думку: 1 Class = 1 Job.

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

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

Найскладніша частина того, що я пережив, - це знати, коли призначити Клас як Оператор, Супервайзор чи Менеджер. Незалежно від цього, вам потрібно буде дотримуватися та позначати його функціональність для 1 відповідальності (Оператор, Супервайзор або Менеджер).

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

Особливо з таким важливим принципом, як "Єдина відповідальність", я особисто вважаю, що є багато причин, чому люди приймають цей принцип.

Деякі з цих причин можуть бути:

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

Також зауважте, що SRP постачається з пакетом принципів SOLID. Дотримуватися SRP та ігнорувати решту - це так само погано, як не робити SRP в першу чергу. Таким чином, ви не повинні оцінювати SRP самостійно, а в контексті всіх принципів SOLID.

Найкращий спосіб зрозуміти важливість цих принципів - це мати потребу.

Коли я був початківцем програмістом, я не задумувався над дизайном, насправді я навіть не знав, що існують шаблони дизайну. Коли мої програми зростали, зміна однієї речі означала зміну багатьох інших речей. Було важко відстежити помилки, код був величезним і повторюваним. Не було багато ієрархії об'єктів, все було скрізь. Додавання чогось нового або видалення чогось старого призведе до помилок в інших частинах програми. Піди розберися.

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

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

Однак, як і ви, я все ще не впевнений у "легкому тестуванні", тому що мені ще не довелося брати участь у тестуванні одиниць.

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

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

Я думаю, що це можна підсумувати одним словом: сфера застосування. Приділіть пильну увагу обсягу артефактів, чим менше речей у будь-якій точці програми, тим краще.

Розширений обсяг = більша складність = більше способів, щоб справи пішли не так.

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

Можливо, для класу є більше ніж одна відповідальність без проблем, але незабаром ви потрапляєте на проблеми із занадто складними класами.

Однак наявність простого правила "лише одна відповідальність" просто полегшує розуміння, коли вам потрібен новий клас .

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