Являются ли шаблоны проектирования действительно языковыми недостатками?

46

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

Обработчики событий на C# являются запеченными версиями шаблона наблюдателя. Подумайте о том, как вы подключаете события на C#, если вам приходилось каждый раз катить своего наблюдателя.
Шаблон посетителей - подробное сближение multimethods, message forwarding, или действительно слабая форма pattern matching.
Командный шаблон обертывает определенное поведение, поэтому вы можете передать объект между методами, который более или менее приближается к первоклассным функциям.
Стратегический шаблон позволяет динамически вставлять поведение в объект, чтобы в любое время вы могли изменять объект, заменяя одно поведение другим. В мире функционального программирования мы называем этот состав функций.
Аннотация заводской шаблон принимает аргумент и возвращает завод в результате. В общем, вы можете думать о фабриках как обертки вокруг функции (точнее, обертки вокруг конструктора). Итак, вы передаете аргументы функции и получаете функцию в результате, делая этот шаблон довольно похожим на currying.
Шаблон Decorator позволяет прикрепить или удалить поведение объекта во время выполнения. В JavaScript вы можете добавлять или удалять функции без явной реализации шаблона декоратора благодаря модели прототипа OO.

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

источник

2009-10-16 17:34:57 Juliet

+1

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

+3

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

+2

@ S.Lott: «Tomorrows super language», вероятно, придет на смену технологической сингулярности и, как я могу себе представить, сделает все шаблоны дизайна устаревшими;) – Juliet

1

Я думаю, что некоторые шаблоны проектирования представляют языковые недостатки, а новые языки включают существующие шаблоны в граждан первого класса. Примером нового языка, использующего существующие шаблоны проектирования на других языках (инъекция зависимостей, неизменность и т. Д.) И включение их в качестве функций уровня первого класса, является NOOP от Google.

источник

2009-10-16 16:56:47 Asaph

10

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

Каждое повторение. Каждое повторение. Каждое повторение.

Некоторые из них получают канонизированную прохладные имена. Они становятся образцами дизайна. Сознательное повторение.

Некоторые из них просто «лучшие практики» или «это сработало для меня». Это шаблоны проектирования без ясности.

Некоторые из них - это «вещи, которые вы обычно делаете». Это шаблоны проектирования без какого-либо осознанного осознания того, что вы повторяете себя.

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

Современные образцы дизайна не являются королевской дорогой к завтрашним языкам. Языковая парадигма не продвигается через ряд «исправлений ошибок на предыдущие языки». Если бы это было так, мы бы никогда не создали Visual Basic.

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

источник

2009-10-16 16:57:08

+0

Хорошо, но вы ответили на его вопрос? –

+0

Я думал, что сделал, но я отредактировал свой ответ, чтобы еще раз увеличить мой пункт. –

+0

Я думаю, что это отличный момент. Похоже, что это более известный случай, когда многие из более известных - в основном, GoF-шаблоны являются излишними на других языках. –

18

Я бы не назвал их дефектами.

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

Вы можете построить здание на уровне нефтеперерабатывающего завода, фрезерный станок, плавильную сталь и собрать здание таким образом.

Вы можете приобрести доски и стальные балки и построить их в здании.

Вы можете приобрести готовые стены и фермы и построить их в здании.

Вы можете приобрести здание и начать с интерьера.

Является ли строительство здания с досками и балки отсутствием сборной стены или дефектной?

источник

2009-10-16 16:58:37

+0

Часто, когда вы говорите об узорах, вы просто используете один и тот же дизайн, но каждый раз вам нужно каждый раз закодировать все это. Аналогия с сборными материалами не содержит ИМО ... которая будет использовать библиотеку (и в этом нет ничего плохого). – 6502

+1

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

1

Мне интересно, сколько вы можете втиснуть в язык, прежде чем он станет слишком «большим».

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

Сколько стоит удержание рук на языке, которое действительно нужно разработчику?

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

источник

2009-10-16 17:00:12

+1

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

+1

Сложнее ли запоминать более крупный язык или язык меньшего размера плюс дополнительные шаблоны? –

+0

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

0

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

источник

2009-10-16 17:00:16 luvieere

2

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

источник

2009-10-16 17:15:17

2

Я думаю, что Эван поднимает увлекательную точку. Возьмите его пример подпрограммы. В ранних языках программирования идея передачи параметров в подпрограмму и возвращение результата была чем-то, что вам нужно было явно кодировать. В современных языках он встроен. Или взять еще один пример: если/then/else встроен в большинство, если не все современные языки. Но в свои дни ассемблера мне пришлось написать код, чтобы это сделать. Не много, конечно, но все же, вы должны были написать инструкцию jump или goto, чтобы обойти блок else. И тот факт, что вам приходилось писать эти вещи сами, означало, что разные программисты сделали бы это по-разному, и было бесконечное соблазн быть умным и сделать это несколько иначе в этой программе, чтобы сделать его более эффективным или получить некоторые другие предполагаемое преимущество.

Последний пример, который приходит на ум, - итераторы. Вам нужно вручную написать их на C++ и в ранних версиях Java, но они встроены в Java 5. Это, возможно, синтаксический сахар, вам просто нужно просто создавать функции итератора. Лично я считаю, что это хорошая функция. Радикально ли это улучшает мою производительность? №

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

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

У меня нет вывода. Я просто согласен, что это увлекательный вопрос.

источник

2009-10-16 18:03:00 Jay

+0

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

+0

Я бы не согласился с тем, что мне было бы трудно думать о конструкции программирования, которая не могла быть достигнута с достаточными усилиями. Вы можете написать подпрограмму или if/else или сделать объектно-ориентированное программирование на ассемблере, это просто сложно. Таким образом, это не сложно, но возможно и невозможно, но это может быть сложно, но практично или слишком много. Но я не думаю, что это был ваш ключевой момент, скорее вы говорите о разнице между «симпатичным» и «блестящим». Правильно? – Jay

0

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

Язык, который может сделать это безгранично, будет без сильного синтаксиса. (или по-другому, который позволяет легко усвоить любой шаблон высокого уровня). см. metalinguistic abstraction

Тот, который приходит мне на ум, является схемой/lisp.

источник

2010-11-04 21:10:26 alvin

1

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

Причина в том, что IMO ясно: если вы видите повторяющийся шаблон (или вы должны его использовать), это означает, что это своего рода копия пасты на логическом уровне. Конечно, это не так плохо, как copy'n paste заявлений, но это все еще избыточность. Я все еще повторяюсь снова и снова.

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

Каждый раз, когда вы снова выполняете одно и то же (включая, например, «ok ... давайте реализуем абстрактную фабрику здесь»), это означает, что это то, что должно было быть выражено на более высоком уровне.

Конечно, иногда вы можете попытаться понять суть чего-то, но повторное использование может быть более уродливым для чтения, чем повторная реализация (я думаю, например, о некоторых частях C++ «высокого уровня» в <algorithm>). Это ИМО - явный признак того, что язык недостаточно выразителен.

источник

2011-01-30 16:39:37 6502

0

Дизайн шаблонов не является слабым языком. Они предоставляют дизайнерские решения для повторяющихся проблем.

Поскольку многие вещи эволюционировали со временем, я думаю, что Enterprise Integration Patterns будут популярны.

Если разные корпоративные приложения должны общаться, эти шаблоны предоставляют наилучшие решения.

Integration Styles Документы разных способов могут быть интегрированы, обеспечивая историческую информацию об интеграционных технологиях. Все последующие шаблоны соответствуют стилю Messaging.
Channel Patterns описывают, как сообщения передаются по каналу сообщений. Эти шаблоны реализуются большинством коммерческих и открытых систем обмена сообщениями.
Message Construction Patterns описывают намерение, форму и содержание сообщений, которые перемещаются по системе обмена сообщениями. Базовым шаблоном для этого раздела является шаблон сообщения.
Routing Patterns обсуждают, как сообщения направляются от отправителя к правильному приемнику. Шаблоны маршрутизации сообщений потребляют сообщение с одного канала и повторно публикуют его, как правило, без изменений, другому каналу на основе набора условий. Шаблоны, представленные в этом разделе, являются специализациями шаблона Message Router.
Transformation Patterns Изменение содержимого сообщения, например, для размещения различных форматов данных, используемых системой отправки и получения. Данные, возможно, придется добавлять, отбирать или существующие данные могут быть перегруппированы. Базовым шаблоном для этого раздела является Message Translator.
Endpoint Patterns описывают, как клиенты системы обмена сообщениями производят или потребляют сообщения.
System Management Patterns описывают инструменты, позволяющие поддерживать сложную систему на основе сообщений, включая работу с условиями ошибок, узкие места производительности и изменения в участвующих системах.

источник

2016-07-13 08:08:33

Являются ли шаблоны проектирования действительно языковыми недостатками?

ответ

Смежные вопросы