Действительно ли шаблоны проектирования действительно важны в наши дни?

107

Я читал «Программисты на работе» и столкнулся с тем фактом, что некоторые из опрошенных в книге специалистов не так увлечены шаблонами проектирования.

Я думаю, что для этого есть две основные причины:

  1. Шаблоны дизайна заставляют нас думать по-своему. Другими словами, почти невозможно изобрести что-то новое (возможно, лучше).

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

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

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

Сергей
источник
79
Если применение шаблона означает копирование и вставку существующего кода, то вы, вероятно, делаете это неправильно
Dyppl
9
используя шаблоны проектирования! = программирование культа грузов
jhocking
11
Название этого вопроса можно перефразировать так: «Неужели в наши дни не нужно заново изобретать колесо?»
Эрик Кинг,
2
Шаблоны дизайна заставляют нас думать по-своему - если вы позволите им. Знание шаблонов позволяет мне рассмотреть возможности для данной проблемы дизайна. Часто это похоже на чтение меню ресторана ... «Нет, нет, интересно, нет, хм, а-ха!». Кроме того, современные языковые особенности часто делают определенные диаграммы образцов, кодифицированные десятилетия назад, архаичными.
Радарбоб

Ответы:

261

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

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

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

Даже если вы не понимаете, о чем я говорю, когда я говорю: «Шаблон наблюдателя идеально подходит для этого», вы сможете легко отключиться и погуглить.

В этом смысле сила шаблонов проектирования никогда не угаснет.

прецизионный самописец
источник
55
+1 за «Я использовал большинство из этих шаблонов задолго до того, как узнал, что у них есть имена». Все они были вокруг долгое время, просто без номенклатуры образцов. В 1991 году я писал синглеты на Си и показывал один более опытному программисту, который никогда не видел его раньше и думал, что это было довольно изящно.
Боб Мерфи
8
Тем не менее, шаблоны также уходят. В 1950-х "вызов подпрограммы" был довольно популярной моделью. В C «объект» является (несколько) популярным шаблоном. Оба они в настоящее время практически вымерли, поскольку они были поглощены современными языками и (в случае подпрограмм) даже в наборе команд современных процессоров.
Йорг Миттаг
9
@Bob Murphy: Argh Singleton :( :( @pdr: точно, шаблоны - это общение о программировании. Применение шаблона, потому что он почти подходит, является самой большой ошибкой, которую можно сделать, и поэтому отражение дизайна не должно быть сделано с точки зрения шаблонов, они должны войти в дизайн только тогда, когда нужно объяснить, о чем вы подумали: «Это почти как <pattern>, за исключением того, что я настроил ...» Я думаю, что сам GOF признает это сам: шаблоны обрезаются / упрощаются видения, они должны быть адаптированы к конкретной ситуации
Матье М.
10
@Jorg: когда исчезла схема «вызова подпрограммы». Как вы думаете, что вызов метода / функции?
Данк
10
@Dunk: Конечно, это зависит от языков, которые вы используете. Я не знаю, какие языки вы используете, но на всех языках, которые я использую сегодня, вызовы подпрограмм являются встроенной функцией языка, а не шаблоном проектирования. Однако, в C, например, вызов метода является шаблоном проектирования, тогда как в Java это встроенная языковая функция.
Йорг Миттаг
15

Шаблоны служат двум основным целям:

  • Предсказуемое устранение напряженности . Шаблоны предназначены для разрешения определенного набора напряжений способом, который, как известно, работает. Кент Бек (Kent Beck), автор « Образцов наилучшей практики» Smalltalk , описывает шаблоны как способ повторить решение, принятое экспертом в аналогичных обстоятельствах. До тех пор, пока напряженность остается неизменной (и часто таковой), модели, которые их устраняют, будут оставаться полезными.

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

Рейн Хенрикс
источник
12

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

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

Витор Пи
источник
3
Мой опыт показывает, что хорошо написанный код соответствует множеству шаблонов проектирования именно потому, что они описывают хорошую практику. Таким образом, чтобы удовлетворить вашего клиента, нужно было просто определить, какие из них вы уже использовали, и поместить их имена в документы. Легко!
Донал Феллоуз
1
@Donal Fellows Вот что я сделал :) В итоге я нашел шаблоны и назвал их, что дало проекту счастливый конец. Моя самая большая проблема в том, что это был очень, очень маленький проект (около недели работы), и он был очень простым: он считывал данные из странного формата данных, делал пару преобразований, собирал данные и помещал их в базу данных.
Vitor Py
@Vitor, я полностью с тобой согласен. Я лично знаю людей, которые думают, что искать шаблон дизайна, который соответствует вашей проблеме / сценарию, - плохая идея! Они предпочитают изобретать велосипед. Я боюсь, что они могут проснуться однажды и попросить меня не использовать классы Java IO и писать свои собственные обработчики IO!
CKing
6

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

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

hardmath
источник
3
«Анти-паттерн» - это просто многословный эвфемизм «плохого».
Майкл Шоу
@hardmath «Анти-паттерн» означает гораздо больше, чем просто «плохо»
GoatInTheMachine
1
@GoatInTheMachine: Согласен, это был комментарий к моему сообщению. Хотя анти-паттерны являются примерами того, чего следует избегать, у них есть характерные черты, которые делают их привлекательным выбором дизайна. Иногда разумно следовать анти-шаблону, зная его недостатки и ловушки, разумно.
hardmath
4

Существует два вида шаблонов проектирования:

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

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

Donal Fellows
источник
Все модели определяются тем, как они разрешают определенный набор напряжений. Пока напряженности одинаковы (и часто они есть, именно поэтому они являются шаблонами ), шаблоны будут оставаться полезными.
Рейн Хенрикс
@ Rein: Но силы, которые создают напряженность, могут быть внутренними или внешними. Разные языки имеют разные внутренние силы (например, шаблоны, относящиеся к интерфейсам, более актуальны для Java, чем для C ++ из-за различий в их системах классов).
Donal Fellows
Определенно. Взгляд на паттерны реализации (книга Java-шаблонов Кента Бека) показывает довольно равномерное распределение между шаблонами общего назначения и шаблонами, которые более специфичны для характеристик Java. Сравнение этой книги с образцами лучших практик Smalltalk также показательно.
Рейн Хенрикс
3

Читать о шаблонах проектирования - это все равно что изучать математику, а не изобретать их заново. Никто не мешает вам добиться значительных успехов в определенной области, если у вас есть четкое понимание того, что было раньше. Как вы думаете, Риман никогда не читал Евклида?

Гас
источник
1

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

Том W
источник
1

Я считаю, что банды четырех сами классифицируют шаблоны проектирования как

общее решение часто встречающейся проблемы *

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

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

Кроме того, .NET Framework имеет встроенный механизм событий для публикации событий для нескольких слушателей, что делает шаблон Observer менее актуальным в этом контексте.

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

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

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

* цитата не может быть на 100% точной, так как она взята из памяти

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

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

Пит
источник
-3

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

Джейкоб Харрингтон
источник
2
это , кажется, не предлагает ничего substantisl над точками сделаны и объяснены в ходе предыдущих ответов
комар