Чому нам потрібно стільки класів з моделей дизайну?

Я молодший розробник серед літніх людей і багато борюся з розумінням їхнього мислення, міркувань.

Я читаю дизайн, керований доменом (DDD), і не можу зрозуміти, чому нам потрібно створити стільки класів. Якщо ми дотримуємось цього методу розробки програмного забезпечення, ми закінчуємо 20-30 класами, які можна замінити щонайбільше двома файлами та 3-4 функціями. Так, це може бути безладно, але це набагато більш ретельно та легко читається.

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

Проста математика:

• 60 рядків фіктивного коду проти 10 класів X 10 (скажімо, у нас абсолютно різні логіки) = 600 рядків безладного коду проти 100 класів + ще кілька, щоб обернути їх та керувати ними; не забудьте додати ін'єкційну залежність.
• Читання 600 рядків безладного коду = один день
• 100 занять = один тиждень, все ж забудьте, хто робить що, коли

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

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

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

Будь ласка, поясніть. Навіщо нам потрібен цей стиль DDD та безліч моделей?

UPD 1 : Я отримав так багато чудових відповідей. Чи можете ви, хлопці, десь додати коментар або відредагувати свою відповідь за посиланням для списку читання (не впевнене, з чого починати, DDD, Шаблони дизайну, UML, Код завершено, Рефакторинг, Прагматичний,. .. стільки хороших книг), звичайно з послідовністю, щоб я також міг почати розуміти і стати старшим, як деякі з вас.

Це проблема оптимізації

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

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

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

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

Складність походить від відносин, а не елементів

Я помічаю у вашому аналізі, що ви дивитесь на кількість - кількість коду, кількість класів тощо. Хоча це щось цікаве, реальний вплив відбувається від відносин між елементами, які вибухають комбінаторно. Наприклад, якщо у вас є 10 функцій, і не маєте уявлення, від чого залежить, у вас є 90 можливих відносин (залежностей), про які ви повинні турбуватися - кожна з десяти функцій може залежати від будь-якої з дев'яти інших функцій, і 9 x 10 = 90. Ви, можливо, не знаєте, які функції модифікують змінні чи спосіб передачі даних, тож у кодерів варто хвилюватися при вирішенні будь-якої конкретної проблеми. На противагу цьому, якщо у вас є 30 класів, але вони розташовані спритно, вони можуть мати всього 29 відносин, наприклад, якщо вони шаруються або розташовані в стек.

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

Ну, по-перше, читачесті та ремонтоздатності часто є в очах глядачів.

Що читається для вас, можливо, не буде для вашого ближнього.

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

DDD

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

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

Таку домовленість об'єктивно не простішим у дотриманні. Однак, це помірно простіше підтримувати, коли всі розуміють, що вони працюють в контексті DDD.

Заняття

Заняття допомагають у ремонтопридатності, читабельності, відкритості тощо… тому що вони є добре відомою умовою .

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

Я знаю, що це звучить дуже абстрактно, але ви можете думати про це так:

За допомогою класів не обов’язково потрібно знати, як працює код у них. Вам просто потрібно знати, за що відповідає клас.

Заняття дозволяють міркувати про вашу заяву з точки зору взаємодії між чітко визначеними компонентами .

Це зменшує когнітивний тягар, коли розмірковуєте про те, як працює ваша програма. Замість того, щоб пам’ятати, що досягає 600 рядків коду , ви можете подумати про взаємодію 30 компонентів .

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

Це здається досить керованим.

Підсумок

По суті, те, що ви бачите, як це роблять старші біси:

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

Потім вони впорядковують їх у легко міркувати про шари.

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

Поясніть, будь ласка, навіщо нам потрібен цей стиль DDD, багато шаблонів?

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

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

Безпосередньо, якщо у вас є дві різні концепції в домені, то вони повинні бути різними в моделі, навіть якщо вони мають спільне використання в пам'яті .

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

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

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

Справедливості: деякі з них також є об'єктно-орієнтованими ушкодженнями мозку. Споконвічно описані Евансом моделі засновані на проектах Java, в яких він брав участь 15+ років тому; стан і поведінка тісно поєднані в цьому стилі, що призводить до ускладнень, яких ви, можливо, хочете уникати; див. Сприйняття та дії Стюарта Хеллоуей або Вступний код Джона Кармака.

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

В інших відповідях є багато хороших моментів, але я думаю, що вони пропускають або не підкреслюють важливої ​​концептуальної помилки, яку ви робите:

Ви порівнюєте зусилля, щоб зрозуміти повну програму.

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

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

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

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

Вплив цього на інші види діяльності:

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

Тому що тестувати код важче, ніж писати код

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

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

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

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

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

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

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

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

Поясніть, будь ласка, навіщо нам потрібен цей стиль DDD, багато шаблонів?

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

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

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

Можливо, настане час, коли ви виявите, що можете скористатись частиною того, про що ви читали, але спочатку не зовсім «вийшло», а може й ні.

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

Чому нам потрібно стільки класів моделей дизайну

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

Існує два ключових посібника для вирішення питання, куди ввести код, і як розрізати завдання на різні одиниці коду:

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

Чому ці два мають бути важливими?

• Згуртованість: метод, який робить багато речей (наприклад, старомодний скрипт CGI, який робить GUI, логіку, доступ до БД тощо) за один тривалий безлад коду) стає непростим. На момент написання запиту спокусливо просто поставити свій потяг думок у довгий метод. Це працює, це легко представити і таке, і ви можете зробити це з цим. Біда виникає пізніше: через кілька місяців ви можете забути, що робили. Рядок коду вгорі може бути в декількох екранах від рядка внизу; легко забути всі деталі. Будь-яка зміна в будь-якому місці методу може порушити будь-яку кількість поведінки складної речі. Буде досить непросто переробляти або повторно використовувати частини методу. І так далі.
• З'єднання: щоразу, коли ви змінюєте одиницю коду, ви потенційно можете порушити всі інші одиниці, які від цього залежать. У строгих мовах, таких як Java, ви можете отримувати підказки під час компіляції (тобто про параметри, оголошені винятки тощо). Але багато змін не викликають таких (тобто зміни поведінки), а інші, більш динамічні, мови не мають таких можливостей. Чим вище зв'язок, тим жорсткіше він може змінити що-небудь, і ви можете перемолоти до зупинки, де для досягнення певної мети необхідне повне переписування.

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

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

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

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

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

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

Досвідчені кодери дізналися:

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

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

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

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

Зробити більше класів та функцій відповідно до використання буде чудовим підходом до вирішення проблем певним чином, які допоможуть у майбутньому вирішити будь-які проблеми.

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

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