言語コンストラクトにデザインパターンが追加されないのはなぜですか？

最近、同僚と話していて、彼の会社はMVCデザインパターンをPHP拡張機能として追加しようとしていると言いました。

彼は、Controllers, Models and Viewsパフォーマンスを向上させるために言語構成要素に追加するCコードを書いたと説明しました。

MVCはWebアプリケーションで広く使用されているアーキテクチャ設計パターンであることがわかりましたが、たとえばコントローラー用の言語構造を持つ言語に出くわす必要があります。

デザインパターンを言語に統合するIMHOは、優れたオブジェクト指向デザインの重要性を強調できます。

それでは、なぜ最もよく使用されるデザインパターン（MVC、ファクトリ、ストラテジーなど）が言語構成要素に追加されないのですか？

質問が広すぎると思われる場合は、質問をPHPのみに制限できます。

編集：

プロジェクトを開発するときにデザインパターンを使用する必要があることを意味するわけではありません。実際、私はそれが機能する限りシンプルに保つ方法論を推進しています。

デザインパターンは、常に言語構造に追加されます。サブルーチンコールデザインパターンを聞いたことがありますか？番号？私もダメ。これは、1950年代初期のデザインパターンであったサブルーチンコールがほとんど瞬時に言語に追加されたためです。最近では、CPUのマシンコード命令セットにも存在しています。

何についてForループデザインパターン？Whileループデザインパターン？スイッチデザインパターン？オブジェクトデザインパターン？クラスデザインパターン？これらはすべて一部の言語に追加されています。

それらのいくつかはそうです。たとえば、イテレータは多くの言語とその標準ライブラリの言語機能です（こんにちは、foreachとyield return）。また、オブザーバーはイベントの形式で頻繁に存在します（PHPではなく、コールバックサブスクリプションを自分で管理する必要があります）。コマンドはWPFのコア機能です。

他の多くは言語サポートの恩恵をあまり受けません（そして、言語をより扱いにくくします）-言語機能を設計できるなら、どのようにコントローラーを簡素化しますか？クラスとして、それらはクラスをサポートするためにすでに存在するすべてのインフラストラクチャの恩恵を受けます-あなたはそれらをインスタンス化し、それらを渡し、例えば他のオブジェクトとしてユニットテストすることができます。

IMOが何らかの言語サポートの恩恵を受けることができるMVCの唯一のコンポーネントはView（公式のテンプレートエンジンを使用）-PHPで既にサポートされています-PHPスクリプトを動的に作成およびロードできます（多くの場合、テンプレートとして使用されるある種の前処理）。

同じことがファクトリーメソッドにも当てはまります-必要な言語機能があれば、それをどのように単純化しますか？一部の言語（C ++など）に欠けている機能の1つに、この型名からオブジェクトを構築する機能がありますが、ほとんどの高レベル言語ではこれを実行できます（そして、便利なファクトリメソッドを作成する必要さえありません）。それ以外は、インスタンス化して返すオブジェクトとオブジェクトを作成できるメソッドを作成するだけです。

いくつかのデザインパターンは実際に言語構成要素として追加されます-組み込まれると「構文」と見なされるため、そのように識別されません。Javaでの例外処理は良い例です-多くの人々は明示的に類似の何かをコーディングしますコア構文の一部ではない場合の設計パターンとして。

しかし、質問に集中するために、言語にあまりにも多くのデザインパターンを追加したくない理由はたくさんあります。

• それらを言語構成要素として追加する必要はありません -すべての設計パターンは他の方法で実装できます
• それは言語を複雑にします -これは言語を学習するのを難しくし、コンパイラとツールを書くのをより難しくするので悪い考えです
• 多くの設計パターンには、代替の実装アプローチがあります。1つのアプローチを選択し、コア言語の一部としてそれを祝福すると、おそらく人々は他のアプローチよりもそのアプローチを使用するようになります（状況によってははるかに良いかもしれません）
• どんな場合でも、デザインパターンへの過度の依存は、おそらく悪い考えです。言語デザイナーは、おそらく、それらをさらに奨励するべきではないことを理解しています。

あなたはメタプログラミング機能（例えばAのLisp）と十分に強力な言語を使用する場合にも、それが実装する言語を自分で拡張することは比較的簡単になり任意のデザインパターンを。5行のマクロを使用して独自のパターンを簡単に追加できる場合は、コア言語のパターンはまったく必要ありません。

最もよく使用されるデザインパターン（MVC、ファクトリ、ストラテジーなど）が言語構成に追加されないのはなぜですか？

これらのパターンのほとんどは、特定の言語サポートなしでほとんどのプログラミング言語で実装できます。JavaのインスタンスMVCを例にとります。

• 直接コーディングできます。
• アプリケーションジェネレーターを使用して実装し、他のボイラープレートの多くを同時に処理できます。
• 「フレームワーク」ライブラリクラスを使用して実装できます。
• アノテーションおよび静的またはランタイムアノテーション処理を使用して実装できます。

これらすべてのオプションを考えると、言語を直接拡張することにはほとんど価値がありません。そして、多くの「欠点」があります。

• それは言語構文を混乱させる傾向があり、（おそらく）初心者プログラマーの生活を難しくします。
• それは言語仕様をより大きく複雑にする傾向があり、言語実装者にとっては難しくなります。（もちろん、仕様が大きいほど、エラーや矛盾が発生する可能性が高くなります。）
• 常に別のパターンを追加するようプレッシャーがかかります...言語の安定性に関する問題/懸念につながります。
• 言語で特定のパターンをサポートすることにより、パターンをサポートする特定の方法を配線します。これは、一部のアプリケーションには適さない場合があります。

彼らです。

関数は、Cの言語構造体になる前のアセンブリコードの設計パターンでした。

仮想関数は、C ++で言語構造体になる前のCの設計パターンでした。

ただし、トレードオフがあります。パターンにボイラープレートコード（2、3個のキーワード）の生成が含まれる場合、それは有用な言語機能であることを示しています。しかし、パターンがシンプルで明確な場合、例えば Cの「for（int i = 0; i <10; i ++）」は、誰もが同じように書くのに役立ちますが、「for i = 0 to 10」よりも大幅に長くはなく、わずかに異なるループを作成するためにそれを変更する方法は明らかです。

「ギャングオブフォー」の本を読むと、次のことが明らかになります。

1. 本のデザインパターンは、実際には他のオブジェクト指向言語でエンコードされたよく知られているsmalltalk規約です。
2. そのため、これらのパターンをオブジェクト指向言語に含めることはできません-それらの言語内でsmalltalkを再実装することになります-smalltalkを直接使用する方が良いでしょう
3. 設計パターンが有用な理由は、現在使用されている言語の役割を強調せず、構文以外の問題に焦点を当てているためです。言語内でこれらのパターンをエンコードすると、設計パターンのこの機能が失われます。
4. 上記の質問の本当の問題は、ソフトウェアを書くことは言語を学ぶことだけではないという点を見落としていることです。言語が直接提供しているものから十分な距離を取って、現在の要件に焦点を合わせることが重要です。

なぜなら、デザインパターンはユーザーコードで完全にうまく実装されているからです。彼の例はPHPであるために発生しましたが、実際にパフォーマンスが必要な場合は、別の言語で作業するか、HipHopなどを取得するだけです。

言語機能は、指定と実装の両方が複雑であり、「現在のイディオムはX」という唯一の目的のために作成することは正当化できません。意味のあるユーザーコードを保存することはほとんどありません。

ええ、古い質問ですが、受け入れられたものを含むセマンティクスダイヤルの「デザインパターン」をどこに設定したかによって、多くの答えに同意しません。

GoF Design Patternsの本の意味では、それは依存していると言えます。たとえば、MVC（実際にはGoFパターンではなく、その型に適合します）は、大量消費のための言語構成体として表現するのはまったく不適切です（特定のPHPプロジェクトでは意味があります）。アーキテクチャパターンとして、テーマには一定のバリエーションがあり、さまざまな状況に応じて多種多様な完全に正当な解釈があります（多くはMVCから遠く離れていますが、おそらくMVCと呼ぶべきではありません）。たとえば、ウェブ上では、httpバリアは、方程式にクライアント側（間違いなく痛みを伴う）を含めようとしているか、より多くの人から「ビュー」を検討しているかによって、やや不自然にフィットします。適切に厳密にサーバー側の視点。

一方、イテレータは非常に一般的な概念であり、非常に多様な方法で多様な構造に適用できます。

コア言語デザインに属するかどうか、サーバー側のWeb固有の言語であるIMOであっても線を引く必要があるのは、数え切れないほどの数のことをやりやすくするために何かが線を越える点ですアーキテクチャパターンのように、過度に具体的でありながら広く実装されていることを行うよりも簡単です。