Що таке програмування на основі шаблону?

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

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

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

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

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

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

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

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

Погляньте на будинки. Вони мають певну схожість. У кожному будинку є мінімум вітальня, кухня, спальня, ванна кімната, туалет. Ніхто не побудує будинок без ванної, правда? Квартири мають візерунок, який відрізняється від багнюків. Замки взагалі мають інший малюнок. Одяг теж має візерунки. Куртка та формальна сорочка мають однаковий базовий дизайн, але вони мають різну поведінку: ви не будете носити ковбойську куртку на співбесіду. Аналогічно класи та їх дії можна групувати відповідно до їх поведінки та дизайну. Дивлячись на загальні елементи їх поведінки, ви створюєте шаблони дизайну для занять.

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

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

Не ігноруйте їх зовсім! Ви можете виявити їх корисними в майбутньому, якщо не зараз. Ключовим підходом до шаблонів дизайну з відкритою думкою є запитання: "Що буде, якщо я не використовую дизайнерські малюнки?" Шаблони не розуміються як «ліки» (хоча ви можете використовувати їх як ліки від проблеми); скоріше, вони втілюють слово "запобігання краще, ніж лікування".

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

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

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

Однак найкраще застосувати зразок ПІСЛЯ ви бачите дійсні випадки використання для декількох проектів, щоб він був статистично справедливим для повторного використання.