Дизайн шаблона как (отсутствует) язык

Question

Иногда люди ссылаются на шаблоны проектирования как на недостающие возможности языка программирования. Чтобы избежать споров о том, что такое шаблон дизайна, скажем, мы рассматриваем только оригинальные шаблоны GoF. Например, шаблон Singleton исчезает в Scala, который поддерживает одноэлементные объекты, используя ключевое слово object.

Существует немного ресурсов вокруг этого, в частности Are Design Patterns Missing Language Features из вики C2, или Are design patterns really language weaknesses? от SO. Но я не мог найти беспристрастное, объективное и всестороннее освещение этого вопроса.

В идеале, мне нужна матрица с шаблонами проектирования (строки) GoF и некоторыми основными языками программирования (столбцами), где каждая ячейка будет ссылаться на обсуждение шаблона на конкретном языке программирования.

Чтобы избежать споров о том, что PL рассмотреть, мы также можем исправить это и выбрать: Java (как статически типизированный представитель OO), Smalltalk (как динамически типизированный представитель), Haskell (как функциональный представитель), Scala (как гибридный оо/функциональный представитель), Lisp (как представитель метапрограммирования), JavaScript (как представитель на основе прототипов). И оставить другие PL для боковых заметок или комментариев. Я знаю, что мы можем спорить об этом выборе, но это уже было бы очень интересно иметь это для этих языков.

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

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

Answer 1

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

В то же время существует множество шаблонов на других языках, которые не нужны на языке ООП. Считайте, что сами объекты являются образцом, когда они реализованы на C или Схеме. В сборке стек вызовов представляет собой шаблон.

Answer 2

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

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

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

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

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