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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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