Почему шаблоны проектирования не добавляются в языковые конструкции?

Недавно я разговаривал с коллегой, который упомянул, что его компания работает над добавлением шаблона проектирования MVC в качестве расширения PHP.

Он объяснил, что они написали C-код для добавления Controllers, Models and Viewsв языковые конструкции для повышения производительности.

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

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

Итак, почему наиболее часто используемые шаблоны проектирования (MVC, Factory, Strategy и т. Д.) Не добавляются в языковые конструкции?

Если вопрос звучит слишком широко, вы можете ограничить вопрос только PHP.

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

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

Шаблоны будут добавлены к конструкции языка все время. Вы когда-нибудь слышали о шаблоне дизайна вызова подпрограммы ? Нет? И я нет. Это потому, что вызовы подпрограмм, которые были образцом проектирования в начале 1950-х годов, были добавлены к языкам практически мгновенно. В настоящее время они даже присутствуют в наборах команд машинного кода процессоров.

А как насчет For Loop Design Pattern? В то время как шаблон дизайна Loop ? Переключатель Design Pattern? Object Design Pattern? Class Design Pattern? Все они были добавлены в некоторые языки.

Некоторые из них. Например, итераторы являются языковой функцией во многих языках и их стандартными библиотеками (привет, foreach и yield return). Обозреватель также часто присутствует в виде событий (не в PHP - вы сами должны управлять подпиской на обратный вызов). Команда является основной функцией в WPF.

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

Единственный компонент MVC, который IMO мог бы извлечь пользу из некоторой языковой поддержки, - это View (с некоторым официальным механизмом шаблонов) - и он уже поддерживается в PHP - вы можете динамически создавать и загружать PHP-скрипты (которые часто какая-то предварительная обработка используется в качестве шаблонов).

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

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

Но чтобы сосредоточиться на вопросе - есть много причин, по которым вы не захотите добавлять слишком много шаблонов проектирования в язык:

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

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

Почему наиболее часто используемые шаблоны проектирования (MVC, Factory, Strategy и т. Д.) Не добавляются в языковые конструкции?

Большинство из этих шаблонов могут быть реализованы на большинстве языков программирования без специальной языковой поддержки. Возьмите, например, MVC в Java:

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

Принимая во внимание все эти параметры, нет никакого смысла в прямом расширении языка. И есть ряд «минусов»:

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

Они есть.

Функции были шаблоном проектирования в ассемблерном коде до того, как они стали языковой конструкцией в C.

Виртуальные функции были шаблоном проектирования в C до того, как они стали конструкцией langiage в C ++.

Тем не менее, есть компромисс. Если шаблон предполагает создание стандартного кода (даже нескольких ключевых слов), это указывает на то, что это будет полезной языковой функцией. Но если шаблон прост и понятен, например. C "for (int i = 0; i <10; i ++)", все равно полезно писать его одинаково, но он не намного длиннее, чем "для i = 0-10", и имеет значительное преимущество в том, что он очевидно, как изменить его, чтобы сделать немного другой цикл.

Прочитайте книгу «Банда четырех», и станет ясно, что:

1. Шаблоны проектирования в книге на самом деле являются хорошо известными соглашениями для разговоров на малых языках, закодированными на других языках ОО.
2. Таким образом, эти шаблоны не могут быть включены в язык OO - это будет переопределять smalltalk внутри этих языков - лучше использовать smalltalk напрямую
3. Чем полезны шаблоны проектирования, так это тем, что они преуменьшают роль используемого в настоящее время языка и фокусируются на других вопросах, помимо синтаксиса. Кодирование этих шаблонов внутри языка потеряло бы эту особенность шаблонов проектирования.
4. Настоящая проблема в приведенном выше вопросе заключается в том, что он упускает из виду тот факт, что написание программного обеспечения связано не только с изучением языка. Важно отойти на достаточном расстоянии от того, какой язык предоставляет напрямую, и сосредоточиться на текущих требованиях.

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

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

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

В смысле книги GoF Design Patterns я бы сказал, что это зависит. Например, MVC (на самом деле не шаблон GoF, а соответствующий этому шаблону) совершенно неуместно выражать в качестве языковых конструкций для массового потребления (хотя это может иметь смысл для конкретного проекта PHP). В качестве архитектурного паттерна существуют постоянные вариации на тему и множество совершенно законных интерпретаций для разных обстоятельств (хотя многие уходят так далеко от MVC, что, вероятно, больше не следует называть это MVC). Например, в Интернете барьер http делает его несколько неловким в зависимости от того, пытаетесь ли вы включить клиентскую сторону (без сомнения, болезненно) в уравнение и что вы рассматриваете как «представление» с более соответственно строго на стороне сервера.

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

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