Итак, «в шаблонах дизайна отсутствуют языковые функции»? [закрыто]

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

Пол Грэхэм сказал: «Питер Норвиг обнаружил, что 16 из 23 шаблонов в шаблонах проектирования были« невидимыми или более простыми »в Лиспе».

или другое предложение, которое подтверждает то, что я недавно видел с людьми, пытающимися симулировать классы в JavaScript:

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

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

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

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

Я не знаю ни о каком глубоком обсуждении или исследовании, которое принимает во внимание все эти вещи.

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

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

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

Редактировать:

В некотором смысле, я говорю о том, что шаблоны позволяют практикующим специалистам думать на более высоком уровне и почти создавать тип DSL для своей среды, оставаясь в рамках синтаксиса своего языка. И да, я видел, что происходит, когда вы применяете их повсюду (см .: AbstractSingletonProxyFactoryBean , да, он существует) или думаете, что это какая-то серебряная пуля. Дело в том, что, хотя им и требуется по-настоящему много времени, чтобы по-настоящему чувствовать себя комфортно, предполагается, что они действительно снижают сложность, делая вещи предсказуемыми / понятными на высоком уровне. Это очень отличается от того, чтобы быть набором патчей для недостатков вашего языка.

Редактировать 2 - добавлен контрпример примера AbstractSingletonProxyFactoryBean, чтобы подшутить над шаблонами. Чтобы быть абсолютно справедливым, если смотреть с точки зрения АОП, даже этот контрпример оправдан.