言語構造にデザインパターンが追加されないのはなぜですか？
最近、私は彼の会社がMVCデザインパターンをPHP拡張として追加することに取り組んでいると述べました。
彼は、パフォーマンスを向上させるために言語構造にControllers, Models and Viewsを追加するためのCコードを作成したと説明しました。
MVCがWebアプリケーションで広く使用されているアーキテクチャ設計パターンであることを知ったのですが、たとえばコントローラー用の言語構成を持つ言語に出会わなければなりません。
設計パターンを言語に統合する私見は、良いOO設計の重要性を強調することができます。
それで、-最も使用されるデザインパターン（MVC、ファクトリ、戦略など）が言語構成に追加されないのはなぜですか？
質問が広すぎるように聞こえる場合は、質問をPHPのみに制限することができます。
編集：
mustプロジェクトを開発するときにデザインパターンを使用することを意味しているわけではありません。実際には、それが機能する限り、それをシンプルに保つ方法論を推進しています。
デザインパターンareは常に言語構成に追加されます。 サブルーチンコールデザインパターンについて聞いたことがありますか？番号？私もダメ。これは、1950年代初頭にあった設計パターンであるサブルーチンコールが即座に言語に追加されたためです。最近では、CPUのマシンコード命令セットにも存在しています。
Forループデザインパターンについてはどうですか？ Whileループデザインパターン？ Switchデザインパターン？ Objectデザインパターン？ Classデザインパターン？これらのすべてが一部の言語に追加されています。
それらのいくつかはそうです。たとえば、イテレータは多くの言語の言語機能とその標準ライブラリです（こんにちは、foreachとyield return）。オブザーバーは、イベントの形でも頻繁に存在します（PHPではない-コールバックサブスクリプションを自分で管理する必要があります）。コマンドは、WPFのコア機能です。
他の多くは言語サポートの恩恵を実際には受けません（そして言語をより扱いにくくします）-それらの言語機能を設計できたら、コントローラーをどのように簡素化しますか？クラスとして、それらはクラスをサポートするためにすでに存在するすべてのインフラストラクチャから恩恵を受けます-それらをインスタンス化し、それらを渡して、そして例えば他のオブジェクトとしてそれらをユニットテストすることができます。
IMOがある種の言語サポートから恩恵を受けることができるMVCの唯一のコンポーネントは、View（いくつかの公式のテンプレートエンジンを使用）であり、PHPでサポートされています）-動的に作成できますそして、PHPスクリプトをロードします（多くの場合、テンプレートとして使用されるある種の前処理で使用されます）。
同じことがファクトリーメソッドにも当てはまります-もしあなたがあなたが望むどんな種類の言語機能も持つことができるなら、あなたはそれをどのように単純化しますか？一部の言語（C++など）に欠けている機能の1つは、この型名からオブジェクトを構築する機能ですが、ほとんどの高水準言語ではこれを実行できます（そして、有用なファクトリメソッドを作成する必要すらありません）。それ以外に必要なのは、インスタンス化してオブジェクトを返すメソッドを作成できることです。
いくつかのデザインパターンは実際に言語構成要素として追加されます-組み込まれた後、人々はそれらを「構文」と見なし始めるため、それらはそのように識別されません。Javaでの例外処理は適切です例-コア構文の一部ではない場合、多くの人がデザインパターンとして同様のものを明示的にコーディングします。
しかし、質問に集中するために、言語にあまり多くのデザインパターンを追加したくない理由はたくさんあります。
- 必要ありません言語構成として追加します-すべての設計パターンは他の方法で実装できます
- 言語を複雑にする-言語を学習しにくくし、コンパイラやツールを書くのが難しくなるため、これは悪い考えです
- 代替の実装アプローチは、多くの設計パターンに存在します。 1つのアプローチを選択し、それをコア言語の一部として祝福すると、おそらく人々が他のアプローチよりもそのアプローチを使用するようになります（状況によってははるかに優れている場合があります）。
- デザインパターンへの過度の依存は、おそらくいずれの場合も悪い考えです。言語デザイナーはおそらく、これ以上奨励すべきではないことを理解しています。
また、メタプログラミング機能を備えた十分に強力な言語（LISPなど）を使用する場合、any設計パターンを実装するように言語を拡張することは比較的簡単です。 5行のマクロで独自のパターンを簡単に追加できる場合は、コア言語のパターンはまったく必要ありません。
最もよく使用されるデザインパターン（MVC、ファクトリー、ストラテジーなど）が言語構造に追加されないのはなぜですか？
これらのパターンのほとんどは、特定の言語サポートがなくても、ほとんどのプログラミング言語で実装できます。たとえば、JavaのMVCを見てみましょう。
- 直接コーディングできます。
- アプリケーションジェネレーターを使用して実装できます。同時に、他の多くのボイラープレートも同時に処理できます。
- 「フレームワーク」ライブラリクラスを使用して実装できます。
- アノテーションと静的またはランタイムアノテーション処理を使用して実装できます。
これらすべてのオプションを考えると、言語を直接拡張することにはほとんど価値がありません。そして、いくつかの「欠点」があります。
- （おそらく）初心者プログラマーの生活をより困難にする言語構文を混乱させる傾向があります。
- それは言語仕様をより大きく、より複雑にする傾向があり、言語実装者にとってそれを難しくします。 （そしてもちろん、スペックが大きいほど、エラーや不整合が発生する可能性が高くなります。）
- さらに別のパターンを追加する必要が常にあります...言語の安定性に関する問題/懸念につながります。
- 言語で特定のパターンをサポートすることで、特定のパターンをサポートする特定のwaysを固定化できます。これは、一部のアプリケーションに適さない場合があります。
彼らです。
関数は、Cで言語構造になる前のアセンブリコードの設計パターンでした。
仮想関数は、C++で言語構造になる前のCの設計パターンでした。
ただし、トレードオフがあります。パターンにボイラープレートコード（2、3のキーワードでも）の生成が含まれている場合、それは有用な言語機能であることを示しています。しかし、パターンが単純で明確な場合、 Cの「for（int i = 0; i <10; i ++）」、それは誰もが同じ方法で書くことは依然として有用ですが、「for i = 0 to 10」よりも大幅に長くはなく、少し異なるループを作るためにそれを変更する方法は明らかです。
「ギャングオブフォー」の本を読んでください。
- この本のデザインパターンは、他のOO言語でエンコードされた、よく知られたSmalltalkの規則です。
- そのため、これらのパターンをOO言語に含めることはできません。これらの言語内でSmalltalkを再実装することになります。Smalltalkを直接使用することをお勧めします。
- デザインパターンが役立つ理由は、デザインパターンが現在使用されている言語の役割を重視せず、構文以外の問題に焦点を当てているためです。言語内でこれらのパターンをエンコードすると、デザインパターンのこの機能が失われます。
- 上記の質問の本当の問題は、ソフトウェアを書くことが言語を学ぶことだけではないという点を逃していることです。どの言語が直接提供しているのかから十分な距離を取って、現在の要件に焦点を合わせることが重要です。
なぜなら、デザインパターンはユーザーコードで完全にうまく実装されているからです。彼の例は、それがPHPであるために起こりましたが、実際にパフォーマンスが必要な場合は、別の言語で作業するか、HipHopなどを入手します。
言語機能は、指定も実装も複雑であり、「現在のイディオムはXである」という唯一の目的のために作成することは正当化できません。意味のあるユーザーコードを保存することはほとんどありません。
ええと、古くなった質問ですが、セマンティクスダイヤルの「デザインパターン」をどこに設定したかによって、受け入れられるものを含め、多くの回答に同意しません。
GoFデザインパターンの本の意味では、それは場合によって異なります。たとえば、MVC（実際にはGoFパターンではないが、その型に適合する）は、大量消費用の言語構成として表現することは完全に不適切です（ただし、特定のPHPプロジェクトでは意味があるかもしれません）。アーキテクチャパターンには、テーマに一定のバリエーションがあり、さまざまな状況でさまざまな完全に正当な解釈があります（多くの場合、MVCから離れているため、おそらくMVCと呼ぶべきではありません）。たとえば、Webでは、 httpバリアは、方程式にクライアント側（間違いなく苦痛）を含めようとしているかどうか、およびより適切に厳密にサーバー側の観点から "ビュー"を検討していることに応じて、やや厄介な適合にします。
一方、イテレータは非常に一般的な概念であり、非常に多種多様な方法で多種多様な構成に適用できます。
何かがコア言語の設計に属しているかどうかに線を引く必要があるのは、サーバー側のWeb固有の言語（IMO）でも、何かが線を横切って、計算できない数のことを簡単に実行できるようになる点です。より簡単であるか、過度に具体化されているが、アーキテクチャパターンのように広範囲に実装されていることを実行するのか。