Виконайте творчість шаблонів дизайну

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

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

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

Як ти гадаєш?

Ваш професор економіки абсолютно коректний.

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

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

Крім того, багато моделей дизайну є моделями підприємств , моделями, які призначені для використання у великих корпоративних програмних системах. Якщо ви дізнаєтесь про чудеса контейнера Inversion of Control, вам захочеться використовувати його в кожній програмі, яку ви пишете, хоча більшість програм насправді цього не потребує (є кращі способи введення залежностей у менші програми, так, як не потрібно контейнер IoC).

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

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

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

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

Якщо ви подивитесь на проблему і запитаєте себе «Що таке модель дизайну для цього?», То ви робите це неправильно, і ви будете менше шансів побачити рішення, яке дивиться вам в обличчя.

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

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

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

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

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

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

Не винаходити молоток, але не ставись до кожної проблеми, як до цвяха

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

Перефразовуючи ваше питання: чи навчитися водінню змусити мене рухатись швидше, чи просто ходити повільніше?

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

Повертаючись до другої частини вашого питання - чи правда ваш професор?

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

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

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

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

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

Це насправді ще одна причина того, що вони не дуже турбуються про них; вони ніде не є настільки універсальними, як іноді стверджується, але насправді дуже сильно прив'язані до конкретних способів структурування програм, які певна мова дозволяє / заохочує. Книга зразків дизайну, написана для Python, була б зовсім іншою, ніж одна, написана для Java, і навіть більше відрізняється, ніж одна, написана для мови, що не є обов'язковою, як Haskell. Краще розуміти на більш глибокому рівні, і ви зможете самостійно відкривати шаблони дизайну будь-якою мовою, з якою ви ознайомитесь.

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

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

Відповідь, звичайно: Так.

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

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

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

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