Чи дизайнерські структури, як правило, є силою для хорошого чи поганого? [зачинено]


33

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

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

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

Відповіді:


53

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

Алекс: Гей, як створюються конфігураційні файли?

Боб: Їх генерує фабрика, яка проживає config.h.

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

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

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


11
+1 у будь-якому випадку, але особливо для "тоді точкових моделей" - саме так ми отримали шаблони в першу чергу, але шукаючи повторюваних проблем .
Френк Ширар

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

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

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

14

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


10

Моделі дизайну чудові, якщо їх правильно використовувати.

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

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

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


+1 чудове пояснення, особливо зазначивши, що їх найкраще використовувати при проектуванні системи. На жаль, знання про те, де і як використовувати ці зразки, здебільшого походять з досвіду рефакторингу попередніх систем, де вони були помічені лише під час впровадження. Тож моя версія - незначне розширення: спочатку подумайте, а потім напишіть код. Потім проаналізуйте результат, рефактор, якщо потрібно і можливо. Наступного разу більше шаблонів стане очевидним перед кодуванням :-)
Лоранд Кедвес

7

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

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

TL; DR: Використовуйте дизайнерські малюнки. Просто не зловживайте ними


Я взагалі десь серед скептичних і цинічних щодо моделей дизайну. Я не думаю, що я безпосередньо мав нагоду хотіти використовувати їх у своїй професійній роботі. Можливо, це тому, що я не використовую Java або "хардкор" OO C ++. Цікаво. Річард Габріель повідомляє, що у розробника дизайнерських моделей (Олександр у будівельній архітектурі) були деякі неприємні невдачі в застосуванні дизайнерських моделей до будівель і, здається, ніколи не досягали якості будівель, які Олександр шукав за дизайнерськими моделями.
Пол Натан

2

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


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

Мої думки точно.
зниклий фактор

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

@Kramii: Наприклад, "Об'єкт функції" / "Функтор" в імперативних мовах програмування є кодовим шаблоном порівняно з функціональними мовами, де функції першого класу. Вам не потрібно нічого там кодувати, це підтримується мовою. Навпаки, вам потрібно використовувати "Шаблон дизайну" під назвою "IO Monad" в Haskell, щоб отримати послідовний імперативний ввід / вивід, який ви отримуєте безкоштовно на необхідних мовах. Я рекомендую дотримуватися теми, з якою я пов’язаний.
LennyProgrammers

1
@ Lenny222: Я прочитав посилання і погоджуюся з вашою думкою, що зразки долають недоліки мови. Однак я не погоджуюся з вашим використанням терміна "котельня". Котловарна плита зазвичай стосується повторної реалізації одного і того ж коду - часто еквівалентного копіювальному коду або принаймні шаблоновим фрагментам коду. ІНТО впровадження моделей дизайну має здійснюватися по-різному відповідно до вимог.
Відновити Моніку Крамія

0

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

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


0

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

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

Ієрархія інкапсуляції шаблону дизайну

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


0

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

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


0

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


0

Шаблони дизайну можуть мати вміння малювати вас, але те саме стосується кодування в цілому. Легко спокуситись, написавши остаточну скриньку інструментів - ви просто повинні пам’ятати про YAGNI, щоб не зупинити вас на курсі, відчути, наскільки потрібна структура додатку. ІМО це лише до індивідуума і ознака їх досвіду / судження.


0

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

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

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

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