Делают ли шаблоны дизайна подавление творчества

Много лет назад я разговаривал с профессором экономики о шаблонах проектирования, о том, как они устанавливают общий язык для программистов и как они хорошо решают известные проблемы и т. Д. И т. Д.

Затем он сказал мне, что это совершенно противоположный подход, который он использовал бы для своих студентов-экономистов. Обычно он представлял проблему и просил их сначала найти решение, чтобы они могли сначала подумать об этом и сначала попытаться найти способы решения проблемы, и только после этого он представил «классическое» решение.

Так что я подумал, действительно ли подход «шаблона проектирования» действительно делает программистов умнее или тупее, поскольку они часто просто получают «правильное решение этой проблемы», а не используют творческий подход и воображение для решения какой-то проблемы в новый и инновационный способ.

Как вы думаете?

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

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

Но их должны использовать только люди, которые понимают, как решить проблему без шаблона, или придумали аналогичный шаблон самостоятельно. В противном случае они будут иметь ту же проблему, что и кодер копирования / вставки; у них будет код, но они не поймут, как он работает, и поэтому не смогут его устранить.

Кроме того, многие из шаблонов проектирования являются шаблонами предприятия , шаблонами, которые предназначены для использования в больших корпоративных системах программного обеспечения. Если вы изучите чудеса контейнера Inversion of Control, вы захотите использовать его в каждой написанной вами программе, даже если большинству программ это не нужно (есть более эффективные способы внедрения зависимостей в меньшие программы, чем не требуется контейнер IoC).

Изучите шаблоны. Понять шаблоны и их правильное использование. Знать, как решить ту же проблему без шаблона (все программные шаблоны являются абстракциями над фундаментальными алгоритмами). Тогда вы сможете уверенно использовать шаблоны программного обеспечения, когда это имеет смысл.

Люди с шаблонами проектирования хотят, чтобы вы смотрели на шаблоны проектирования, - это набор решений, которые вы можете применить, если возникнут похожие проблемы. Они не хотят, чтобы вы думали о них как о единственно возможных решениях, данных Богом Моисею, высеченному в каменных скрижалях на горе.

К сожалению, некоторые люди воспринимают их как нечто более близкое к священному писанию, чем к куче примеров проектов, из которых можно извлечь уроки. Это убивает креативность и создает культ груза.

Ваш профессор экономики упомянул, что нужно представить студентам проблему и попросить их сначала решить ее, что является хорошей методикой обучения, но у него было решение показать их. Хорошо иметь в голове кучу решений для множества разных проблем, и это то, что пытается сделать Design Patterns. Я думаю, что в некотором смысле это не удается (Синглтон поощряет плохие подходы, близорукий акцент на императивных ОО и т. Д.), Но его можно использовать с умом и вкусом. Однако ошибочно думать, что каждое возможное примерное решение в программном обеспечении должно быть официальным шаблоном проектирования.

Если вы посмотрите на проблему и спросите себя: «Каков шаблон проектирования для этого?», То вы делаете это неправильно, и у вас будет меньше шансов увидеть решение, которое смотрит вам в лицо.

Если вы посмотрите на проблему и спросите себя: «Как я могу решить эту проблему?», То, если есть решение, не основанное на шаблонах, вы увидите его, и если есть шаблон, который подходит, вы тоже это увидите.

Я также думаю, что ваш профессор экономики прав, и это способ научиться чему-либо в первую очередь; Однако давайте посмотрим на это так: вы бы сохранили Колесо в тайне и позволили бы всем заново его изобрести, ради Творчества ? Я ожидаю, что вы скажете «Нет», потому что не все люди созданы / способны изобрести свои колеса - и если они это сделают, они это сделают в какой-то момент, независимо от того, знают ли они о существовании колеса или не.

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

Я думаю, что это то же самое для большинства из нас. Если никто не говорит вам о DI - как хорошая практика, то сколько корпоративных приложений должно бороться или терпеть неудачу, пока их разработчики не усвоят урок?

Второй момент - отраслевые стандарты . Если вы не будете учить MVC веб-разработчикам, то готовы ли вы столкнуться со всеми этими нестандартными структурами, с которыми вам нужно потратить некоторое время, чтобы сначала изучить их способ работы, а затем вы понимаете, что некоторые из этих структур могут У меня есть хорошая идея, но у большинства из них будут серьезные недостатки дизайна, которые могут иметь серьезные последствия для вашего программного проекта - даже хорошо известные фреймворки все еще время от времени борются с недостатками дизайна.

Но что произойдет, если у нас появятся все эти хорошие идеи и соберем их все воедино, и эти умные разработчики возьмут все хорошее из всех этих экспериментов и создадут действительно классную структуру, которая лучше всего подходит для этой конкретной проблемы? Тогда вы только что создали шаблоны проектирования . Если вы живое существо, то другого пути нет; Даже животные следуют передовым методам и моделям дизайна в своей повседневной жизни.

Не изобретайте молоток, но не относитесь к каждой проблеме как к гвоздю

Шаблоны программирования значительно экономят время, потому что они дают вам готовые к использованию решения, хорошо документированы и протестированы со средними случаями, о которых вы легко можете забыть. Но вам нужно научиться (и подумать), когда их использовать.

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

Изучение того, как использовать шаблон программирования, не означает, что вы не должны заниматься поиском собственных решений. По-прежнему будет достаточно проблем, чтобы проявить свою креативность. Знание шаблонов программирования позволит вам быстро справиться с хорошо известными проблемами и сосредоточиться на тех, которые менее тривиальны.

Возвращаясь ко второй части вашего вопроса - ваш профессор прав?

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

Это причина, по которой вы сначала учите студентов программировать, а шаблоны будут представлены в следующих семестрах.

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

Я склонен думать, что шаблоны проектирования на самом деле не так уж и ценны для работающих программистов. Если вы полностью понимаете принципы, используемые в данном шаблоне проектирования, то в ситуации, когда это хорошее решение, вы, естественно, будете склонны создавать его (или что-то подобное) в любом случае, как само собой разумеющееся, даже если вы не знали что это был шаблон с именем. Какое бы время вы ни потратили на изучение шаблонов, лучше потратить время на изучение того, как думать о коде в целом. Если ваши навыки «решения проблем в целом» не на пустом месте, то вы не сможете написать хороший код, независимо от того, насколько вы хороши в применении некоторого набора шаблонов. И если ваши навыки «решения проблем в целом» хороши, то вы можете решать проблемы, даже если вы не знаете ни одного паттерна.

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

На самом деле это еще одна причина, по которой они не очень заботятся; они не настолько универсальны, как иногда утверждают, но на самом деле очень сильно связаны с конкретными способами структурирования программ, которые позволяет / поощряет определенный язык. Книга шаблонов проектирования, написанная для Python, будет полностью отличаться от книги, написанной для Java, и даже более отличаться, чем книга, написанная для неимперативного языка, такого как Haskell. Лучше понять на более глубоком уровне, и вы сможете самостоятельно находить шаблоны проектирования на любом языке, с которым знакомы.

Коммерция и образование преследуют разные цели. Если бы я обучал студентов шаблонам проектирования, я бы использовал тот же подход. Но в производственной среде время и эффективность - это все.

Более того, (макро) экономика вне классной комнаты - это совсем другое. Видите ли вы, как правительства говорят: «Ого! Теперь нам очень скучно делать налоги и все такое же, так что давайте попробуем что-нибудь сверхъестественное на этот раз»? Нет, нет, потому что такие дикие эксперименты могут разрушить экономику без возможности восстановления. Вместо этого они склонны придерживаться проверенных подходов: повысить процентную ставку, объявить налоговые каникулы и т. Д. Другими словами, они полагаются на шаблоны проектирования.

Ответ, конечно: да.

Шаблоны проектирования сами по себе являются замечательным инструментом обучения, если нужно время, чтобы понять, как они работают и почему они приносят ценность, которую они приносят.

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

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

Шаблоны дизайна, конечно, менее креативны. Вот и вся идея. Творчество является дефицитным ресурсом. Вы не должны тратить его на проблемы, которые не требуют творчества. Это гораздо проще, быстрее и с большей вероятностью сработает, если вы решите проблему так же, как сотни разработчиков до вас. Скучный, неинтересный код, который делает свою работу, на самом деле хорош.