それでは、「デザインパターンに言語機能が欠けていますか？」[閉まっている]

ここでプログラマーに、この質問への答えを見ました：動的で弱く型付けされた言語で、設計パターンとOOPプラクティスに関する考え方はどのように変わりますか？そこで、率直なタイトルの記事へのリンクを見つけました：デザインパターンには言語機能がありません。しかし、私にとって非常にキャッチーであると思われるスニペットを見つけた場合、それはおそらく次のようなインセンティブがあるので、経験に対して検証することができます：

PaulGraham氏は、「Peter Norvigは、Design Patternsの23パターンのうち16パターンがLispで「見えない、または単純である」ことを発見しました。」

JavaScriptでクラスをシミュレートしようとしている人に最近見たものを確認する別の文：

もちろん、ほとんどの言語が「機能」パターン、「クラス」パターン、または他の多くのことを当たり前だと言っていることはありません。ほとんどの言語が組み込み機能として提供しているからです。OTOH、純粋にPrototypeOrientedLanguageのプログラマーですか？プロトタイプを使用してクラスをシミュレートすると便利かもしれません...

また、デザインパターンが通信ツールであることも考慮しています。アプリケーションの構築に参加した経験が限られている場合でも、たとえばアンチパターン（非効率的および/または逆効果）として見ることができるため、小規模のPHPチームに中小規模のイントラネットアプリのGoFパターンを学習させる必要があります。規模、範囲、目的が何が効果的および/または生産的であるかを決定できることは承知していますが、それでも技術的な概要を見つけることができませんでした。

OOPと機能が混在し、なおかつ保守可能である小さな商用アプリケーションを見ました。シングルトンを記述するために、たとえばPythonで多くの人が必要かどうかはわかりませんが、私にとっては単純なモジュールでも同じことができます。

設計パターン対回避策対それを行う簡単な方法、または言語機能による置換を考慮した研究、網羅的な記事、または他の形式の説明はありますか？

私は、これらすべてを考慮に入れた詳細な議論や研究を知りません。

そうは言っても、「設計パターンはオブジェクト指向言語の欠落している機能にパッチを当てているだけです」という議論全体は、私の意見では少し薄いです。はい、いくつかのデザインパターンはまさに、他の言語Xには存在しない共通のギャップを埋めるものです。これらは、通常、GoFブックの元のパターンの一部または多くのような低レベルでシンプルなデザインパターンです。

しかし、設計パターンはこれらの単純なものをはるかに超えており、それらを欠落した言語機能と呼ぶと想像力が広がります。Fowlerのエンタープライズアプリケーションパターンのカタログをざっと見て、それらがすべて言語のコア定義の一部だったらどうなるかを考えてください。ドメイン固有の言語（エンタープライズアプリケーション用の DSL）（そして非常に複雑）になって。

だから、これは本当に、デザインパターンは、特定の問題（一般的な汎用言語で適用されることが多い）に対して再利用可能なソリューションを思いつく方法です。ここで通信も行われます。「Active Recordsを使用します」と言われた場合、さまざまなアプローチが何であるかを議論することなく、あなたのアプリケーションについてすでに多くのことを知っています。そのため、デザインパターンは言語仕様にパッチホールを作ります。彼らがすることはそれだけですか？いいえ-ロングショットではありません。

編集：

ある意味で、私が言っているのは、パターンはオブジェクト指向の実践者がより高いレベルで考え、環境のタイプのDSLをほとんど言語の構文内にとどめながら構築できることです。そして、はい、どこにでもそれらを適用すると何が起こるかを見てきました（参照： AbstractSingletonProxyFactoryBean、はい、存在します）、またはそれらは何らかの特効薬であると思います。重要なのは、本当に慣れるまでに長い時間がかかる一方で、物事を高レベルで予測可能/理解可能にすることで、実際に複雑さを軽減することになっているということです。これは、あなたの言語の障害に対するパッチキットとは非常に異なります。

編集2-パターンでいくつかの楽しみを突くために、AbstractSingletonProxyFactoryBeanの反例を追加しました。完全に公平にするために、AOPライトから見た場合、この反例でも防御できます。