Чи справді дизайнерські зразки справді важливі?

Я читав «Кодери на роботі» і стикався з тим, що деякі з опитаних у книзі професіоналів не так захоплені дизайнерськими моделями.

Я думаю, що для цього є дві основні причини:

1. Шаблони дизайну змушують нас мислити в їх термінах. Іншими словами, винайти щось нове (можливо, краще) майже неможливо.

2. Шаблони дизайну не тривають вічно. Мови та технології швидко змінюються; тому зразки дизайну з часом стануть неактуальними.

Тому, можливо, важливіше навчитися правильно програмувати без особливих шаблонів і не навчитися їх.

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

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

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

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

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

У цьому сенсі сила дизайнерських моделей ніколи не згасне.

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

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

Шаблони служать двом основним цілям:

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

• Мультиплікатор сили зв'язку : Шаблони дозволяють нам сказати багато з невеликим. Вони використовують невеликий набір потужних, добре зрозумілих концепцій, застосовних у найрізноманітніших проблемних просторах. @ pdr відповідь мертва щодо комунікативної цінності моделей.

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

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

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

Але шаблони дизайну та анти-шаблони формують ресурс для цих дискусій. Потрібно оцінити уроки речей, які добре (або ні) спрацювали, і як скористатися (або пом’якшити) наслідки вибір дизайну. Хороший колектив міг би створити власний словниковий запас для таких дискусій, але насправді це не так вже й погано, коли посилатися на стандарти дефакто, розроблені авторами, які там були, зробили це.

Існує два типи моделей дизайну:

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

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

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

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

Я вважаю, що банда з чотирьох класифікує дизайнерські зразки як

загальне рішення поширеної проблеми *

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

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

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

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

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

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

* цитата може бути не на 100% точною, оскільки вона взята з пам'яті

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

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

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