Використовуючи Принцип єдиної відповідальності, що являє собою "відповідальність?"

Здається, досить зрозуміло, що "Принцип єдиної відповідальності" не означає "лише одне". Ось для чого методи.

public Interface CustomerCRUD
{
    public void Create(Customer customer);
    public Customer Read(int CustomerID);
    public void Update(Customer customer);
    public void Delete(int CustomerID);
}

Боб Мартін каже, що "заняття повинні мати лише одну причину для зміни". Але це важко переконатися, якщо ви новачок у програмі SOLID.

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

То як же це зробити? Як Ви визначаєте, які обов'язки повинен мати кожен клас, і як Ви визначаєте відповідальність у контексті СРП?

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

Наприклад:

Нова вимога бізнесу: Користувачі, розташовані в Каліфорнії, отримують спеціальну знижку.

Приклад "хорошої" зміни: мені потрібно змінити код у класі, який обчислює знижки.

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

Або:

Нова нефункціональна вимога: ми почнемо використовувати Oracle замість SQL Server

Приклад доброї зміни: Просто потрібно змінити один клас на рівні доступу до даних, який визначає, як зберігати дані в DTO.

Погана зміна: мені потрібно змінити всі мої класи бізнес-шару, оскільки вони містять логіку, орієнтовану на SQL Server.

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

Як мінімум, ваші заняття повинні відокремлювати логічні проблеми від фізичних. Великий набір прикладів можна знайти в System.IOпросторі імен: там можна знайти різні види фізичних потоків (наприклад FileStream, MemoryStreamчи NetworkStream) і різних читачів і письменників ( BinaryWriter, TextWriter) , які працюють на логічному рівні. Поділяючи їх таким чином, ми уникаємо комбинаторного вибуху: замість того , FileStreamTextWriter, FileStreamBinaryWriter, NetworkStreamTextWriter, NetworkStreamBinaryWriter, MemoryStreamTextWriter, і MemoryStreamBinaryWriter, ви просто підключити письменник і потік , і ви можете мати те , що ви хочете. Тоді пізніше ми можемо додати, скажімо, анну XmlWriter, не потребуючи повторної реалізації для пам'яті, файлів та мережі окремо.

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

Йдеться про те, що, на ваш досвід , ймовірно, зміниться.

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

Отже, якщо підрозділи не керуються ймовірними змінами, вони справді не обслуговуються SRP ^1, якщо YAGNI є більш застосовним. Обидва служать одній і тій самій кінцевій меті. І те й інше - питання судження - це, сподіваємось, приправлене рішення.

Коли дядько Боб пише про це, він пропонує нам подумати про "відповідальність" з точки зору того, "хто просить зміни". Іншими словами, ми не хочемо, щоб Партія А втрачала роботу, оскільки Партія В попросила зміни.

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

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

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

^{1. Щоб бути зрозумілим, це не означає, що вони погані . Вони можуть бути чудовими підрозділами, які значно покращують читабельність коду. Це просто означає, що їх не керує СРП.}

Я слідую, щоб "заняття мали лише одну причину для зміни".

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

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

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

Ще одна груба метрика - крок ліфта. Традиційні ліфтові майданчики - "якщо ви були в ліфті з інвестором, чи можете ви продати його за ідею?". Стартапам потрібно мати прості, короткі описи того, що вони роблять - на що їхня увага. Так само класи (та функції) повинні мати простий опис того, що вони роблять . Не "цей клас реалізує якийсь фубар, щоб ви могли використовувати його в цих конкретних сценаріях". Щось ви можете сказати іншому розробнику: "Цей клас створює користувачів". Якщо ви не можете повідомити , що іншим розробникам, ви збираєтеся отримати помилки.

Ніхто не знає. Або, принаймні, ми не можемо домовитися про одне визначення. Саме це робить SPR (та інші принципи SOLID) досить суперечливими.

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

Я заперечую, що головна мета СРП - не жорстке правило. Потрібно нагадати нам пам’ятати про згуртованість у коді та завжди докладати певних зусиль для визначення того, який код є згуртованим, а що ні.

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

• Відповідальність співмірна з повноваженнями.
• Жодна з двох організацій не повинна відповідати за одне і те ж.

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

Окрім цих двох, третім принципом здається розумним:

• Відповідальність може бути делегована

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

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

На цій конференції в Єлі дядько Боб наводить цей кумедний приклад:

Він каже, що Employeeмає три причини зміни, три джерела вимог до змін, і дає це жартівливе і чітке , але все-таки ілюстративне пояснення:

• Якщо CalcPay()метод має помилку і коштує компанії мільйони доларів США, фінансовий директор звільнить вас .

• Якщо ReportHours()метод має помилку і коштує компанії мільйони доларів США, COO звільнить вас .

• Якщо в WriteEmmployee(методі) виникла помилка, яка викликає стерти багато даних і коштує компанії мільйонів доларів США, CTO звільнить вас .

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

Він дає це рішення, яке вирішує порушення SRP, але все ж має вирішити порушення DIP, яке не показано на відео.

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

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

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

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

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

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

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

Використовуйте занадто багато непрямих і це знову стає безладом ... як і для інших принципів, цей буде конфліктувати з іншими, такими як KISS, YAGNI тощо. Все - це питання балансу.

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

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

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

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

Тому не зосереджуйтеся лише на тому, що може змінитися - все можливе може змінитися в майбутньому. Зосередьтеся на тому, що може самостійно змінитися. Зміни, як правило, незалежні, якщо вони викликані різними суб'єктами.

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

Цитувати дядька Боба, який винайшов цей термін:

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

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

Хороша стаття, в якій пояснюються принципи програмування SOLID та наводяться приклади коду як наступних, так і не слідуючих цим принципам, є https://scotch.io/bar-talk/solid-the-first-five-principles-of-object-oriented- дизайн .

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

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

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

Це простий приклад (і легше зрозуміти, читаючи статтю, оскільки вона має фрагменти коду), але демонструє основну ідею SRP.

Перш за все, у вас є насправді дві окремі проблеми: проблема, які методи поставити у ваших класах, і проблема роздуття інтерфейсу.

Інтерфейси

У вас є цей інтерфейс:

public Interface CustomerCRUD
{
  public void Create(Customer customer);
  public Customer Read(int CustomerID);
  public void Update(Customer customer);
  public void Delete(int CustomerID);
}

Імовірно, у вас є кілька класів, які відповідають CustomerCRUDінтерфейсу (інакше інтерфейс не потрібний), а також деяка функція, do_crud(customer: CustomerCRUD)яка виконує відповідний об'єкт. Але ви вже порушили СРП: ви зв'язали ці чотири чіткі операції разом.

Скажімо, пізніше ви працювали б над переглядами бази даних. Подання бази даних має тільки на Readдоступний метод для цього. Але ви хочете записати функцію, do_query_stuff(customer: ???)яку оператори прозоро використовують або на повномасштабних таблицях, або на видах; він використовує лише Readметод, зрештою.

Тож створіть інтерфейс

публічний інтерфейс CustomerReader {публічний читач клієнта (customerID: int)}

та розподіліть свій CustomerCrudінтерфейс як:

public interface CustomerCRUD extends CustomerReader
{
  public void Create(Customer customer);
  public void Update(Customer customer);
  public void Delete(int CustomerID);
}

Але кінці не видно. Можуть бути об’єкти, які ми можемо створювати, але не оновлювати і т. Д. Цей кролячий отвір занадто глибокий. Єдиний розумний спосіб дотримуватися принципу єдиної відповідальності - зробити так, щоб усі ваші інтерфейси містили саме один метод . Перехід фактично слід за цією методологією з того, що я бачив, з переважною більшістю інтерфейсів, що містять одну функцію; якщо ви хочете вказати інтерфейс, який містить дві функції, вам доведеться незграбно створити новий інтерфейс, який поєднує ці дві. Незабаром ви отримаєте комбінаторний вибух інтерфейсів.

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

let do_customer_stuff customer = customer.read ... customer.update ...

що називає всі способи, які нам подобаються OCaml використовуватиме висновок типу, щоб визначити, що ми можемо передати будь-який об’єкт, який реалізує ці методи. У цьому прикладі було б визначити, що customerмає тип <read: int -> unit, update: int -> unit, ...>.

Заняття

Це вирішує безлад інтерфейсу ; але нам ще належить реалізувати класи, які містять кілька методів. Наприклад, чи слід створити два різні класи, CustomerReaderі CustomerWriter? Що робити, якщо ми хочемо змінити, як читаються таблиці (наприклад, зараз ми кешуємо свої відповіді в редакторі раніше після отримання даних), але тепер, як вони записуються? Якщо ви дотримуєтесь цього ланцюжка міркувань до його логічного завершення, ви нерозривно ведете до функціонального програмування :)

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

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

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

Але вдало розуміючи, що на перший погляд, коли ви вперше чуєте про SOLID.

Я бачу багато коментарів, які говорять про те, що SRP та YAGNI можуть суперечити іншим , але YAGN, який я застосовував TDD (GOOS, London School), навчив мене думати і розробляти свої компоненти з точки зору клієнта. Я почав проектувати свої інтерфейси з того, що найменше хотів би, щоб це робив кожен клієнт, тобто так мало він повинен робити . І цю вправу можна зробити без будь-яких знань TDD.

Мені подобається техніка, описана дядьком Боб (я не можу пригадати звідки, на жаль), яка йде на зразок:

Запитайте себе, що робить цей клас?

Чи відповідь містила або І, або Ор

Якщо так, витягніть цю частину відповіді, це відповідальність за себе

Ця методика є абсолютною, і, як сказав @svidgen, SRP - це виклик судження, але коли вивчаєш щось нове, абсолютні речі найкращі, то простіше просто завжди щось робити. Переконайтесь, що причина, яку ви не розлучаєте, - це; освічена оцінка, а не тому, що ви не знаєте, як це зробити. Це мистецтво, і воно потребує досвіду.

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

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

Теоретично без SRP у вас не було б ніяких залежностей ...

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

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

На це немає чіткої відповіді. Хоча питання вузьке, пояснень немає.

Для мене це щось на зразок бритва Оккама, якщо ви хочете. Це ідеал, де я намагаюся порівняти свій поточний код. Це важко забити це простими і простими словами. Ще одна метафора - це «одна тема», яка є настільки ж абстрактною, тобто важкою для розуміння, як «одна відповідальність». Третім описом буде "робота з одним рівнем абстракції".

Що це означає практично?

Останнім часом я використовую стиль кодування, який складається здебільшого з двох фаз:

Першу фазу найкраще описати як творчий хаос. У цій фазі я записую код у міру течії думок - тобто сирих і негарних.

Фаза II - це повна протилежність. Це як прибирання після урагану. Для цього потрібна найбільше праці та дисципліни. А потім я дивлюся на код з точки зору дизайнера.

Зараз я працюю здебільшого в Python, що дозволяє мені мислити предмети та класи пізніше. Перша фаза I - я записую лише функції та поширюю їх майже випадковим чином у різних модулях. На II фазі , після того, як я все розібрався, я детальніше ознайомлююся з тим, який модуль має справу з якою частиною рішення. І, переглядаючи модулі, у мене виникають теми . Деякі функції пов'язані тематично. Це хороші кандидати на заняття . І після того, як я перетворив функції на класи - що майже робиться з відступом та додаванням selfдо списку параметрів у python;) - я використовую, SRPяк Occam's Razor, щоб викреслити функціональність для інших модулів та класів.

Поточним прикладом може бути написання функцій невеликого експорту днями.

Виникла потреба у форматі csv , excel та комбінованих листах excel на блискавці.

Простий функціонал виконувався в трьох видах (= функції). Кожна функція використовувала загальний метод визначення фільтрів та другий метод для отримання даних. Потім у кожній функції відбувалася підготовка експорту і була доставлена ​​у відповідь від сервера.

Занадто багато рівнів абстракції змішалося:

I) розгляд вхідного / вихідного запиту / відповіді

II) визначення фільтрів

III) отримання даних

IV) перетворення даних

Найпростішим кроком було використання однієї абстракції ( exporter) для обробки шарів II-IV на першому кроці.

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

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

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

На наступному кроці я розбив фактичні механізми експорту: Де потрібно було записувати у тимчасовий файл, я розділив це на два "обов'язки": один для фактичного запису даних на диск та інший, який стосувався фактичного формату.

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

Як Ви визначаєте, які обов'язки повинен мати кожен клас, і як Ви визначаєте відповідальність у контексті СРП?

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

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

Уявіть мене як кодуючого Боб Росса ;)

Що я намагаюся зробити, щоб написати код, що відповідає SRP:

• Виберіть конкретну проблему, яку потрібно вирішити;
• Напишіть код, який його вирішує, напишіть все одним методом (наприклад: основний);
• Ретельно проаналізуйте код і, спираючись на бізнес, спробуйте визначити обов'язки, які видно у всіх операціях, що виконуються (це суб’єктивна частина, яка також залежить від бізнесу / проекту / замовника);
• Зверніть увагу, що вся функціональність вже реалізована; далі - лише організація коду (відтепер у цьому підході жодна додаткова функція чи механізм не буде реалізована);
• На основі обов'язків, визначених у попередніх кроках (які визначені на основі бізнесу та ідеї "одна причина змінити"), витягніть для кожного окремий клас чи метод;
• Зверніть увагу, що цей підхід стосується лише СПР; в ідеалі тут повинні бути додаткові кроки, намагаючись дотримуватися й інших принципів.

Приклад:

Проблема: отримати від користувача два числа, обчислити їх суму та вивести результат користувачеві:

//first step: solve the problem right away
static void Main(string[] args)
{
    Console.WriteLine("Number 1: ");
    int firstNumber = Convert.ToInt32(Console.ReadLine());

    Console.WriteLine("Number 2: ");
    int secondNumber = Convert.ToInt32(Console.ReadLine());

    int result = firstNumber + secondNumber;

    Console.WriteLine("Hi there! The result is: {0}", result);

    Console.ReadLine();
}

Далі спробуйте визначити обов'язки на основі завдань, які необхідно виконати. З цього витягніть відповідні класи:

//Responsible for getting two integers from the user
class Input {
    public int FirstNumber { get; set; }
    public int SecondNumber { get; set; }
    public void Read() {
        Console.WriteLine("Number 1: ");
        FirstNumber = Convert.ToInt32(Console.ReadLine());

        Console.WriteLine("Number 2: ");
        SecondNumber = Convert.ToInt32(Console.ReadLine());
    }
}

//Responsible for calculating the sum of two integers
class SumOperation {
    public int Result { get; set; }
    public void Calculate(int a, int b) {
        Result = a + b;
    }
}

//Responsible for the output of some value to the user
class Output {
    public void Write(int result) {
        Console.WriteLine("Hello! The result is: {0}", result);
    }
}

Потім програма, що реконструюється, стає:

//Program: responsible for main execution.
//Gets two numbers from user and output their sum.
static void Main(string[] args)
{
    var input = new Input();
    input.Read();

    var operation = new SumOperation();
    operation.Calculate(input.FirstNumber, input.SecondNumber);

    var output = new Output();
    output.Write(operation.Result);

    Console.ReadLine();
}

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

З книги Роберта К. Мартінса « Чиста архітектура: Посібник майстра щодо структури та дизайну програмного забезпечення» , опублікованої 10 вересня 2017 року, Роберт пише на сторінці 62 наступне:

Історично СРП було описано так:

Модуль повинен мати одну, і лише одну, причину для зміни

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

Модуль повинен відповідати одному, і лише одному користувачеві або зацікавленій особі

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

Таким чином, остаточним варіантом СРП є:

Модуль повинен відповідати одному та лише одному актору.

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