デザインパターンと複数のプログラミング言語
ここでは、GOFブックにあるデザインパターンを参照します。最初に、私がそれをどのように見ているか、パターンをデザインし、複数の言語を知っているいくつかの特殊性があります。たとえば、Javaではシングルトンが本当に必要ですが、Pythonモジュールを作成せずにそれを実行できます。JavaScriptのすべてのGOFパターンを書き込もうとするWikiがどこかで見られ、すべてのエントリが空でした。その適応を行うのは困難な作業である可能性があるためです。
デザインパターンを使用していて、OOPパラダイムをサポートする複数の言語をプログラミングしていて、デザインパターンにどのようにアプローチすればよいかについてヒントを得ることができる人がいる場合。すべての言語で私を助けるアプローチ私は使用しています（Java、JavaScript、Python、Ruby）：
GOFの設計パターンを正確に知らなくても良いアプリケーションを作成できますか、それとも重要なそれらのいくつかだけが必要かもしれません。そうであれば、特定の言語のGOFに代わるものがあり、プログラマーまたはチームが独自に設計する必要がありますパターンセット？
最初に理解しておくべきことは、デザインパターンはデザインツールではないということです。 彼らはコミュニケーションツールです 。 GOFの設計パターンを知らなくても、優れたアプリケーションを作成できますか？もちろんです。あなたはおそらくあなたがすでにデザインパターンを使用していることに気付くでしょう、あなたはそれを知らないだけです。結局のところ、これらは一般的な問題に対する一般的な解決策です。しかし、同僚にもっと良い方法を教えてもらえますか？簡単ではありません。
理解しておくべき2番目のことは、一部のデザインパターンは非常に一般的であるため、現在、ほとんどの現代の言語に組み込まれているということです。たとえば、C＃ではオブザーバーパターンは必要ありません。イベントがあります（これはオブザーバーパターンですが、C＃開発者に「そこでオブザーバーを使用する」と言う必要はありません）。
3つ目は、GoFデザインパターンの本が書かれたことです。 javaのいくつかのバージョン 多くの月の前に、クラス指向の言語に非常に基づいていました。 JavaScriptはクラス指向の言語ではなく、プロトタイプ指向の言語であり、PythonおよびRubyは両方とも動的です。そのため、GoFパターンの一部はそれらの言語には無関係です（ただし、そうでない場合もあります）。
今日、はるかに便利なのは、Martin Fowlerの Patterns of Enterprise Application Architecture で説明されているパターンです。
以上のことから、GoFパターンを理解することは、それらを理解する他の開発者とのコミュニケーションを促進するために役立つだけです。 GoFの本は乾燥していて、頭を動かすのが難しい場合があります-それらはまた、興味深い思考の練習になります。チームのアプリケーションで一般的なパターンを表示するように求められたり、 独自のパターンを記述したり したりできます。また、あまり正確ではありません（たとえば、アダプタ、プロキシ、ファサードの違いについて話すとき）。
いくつかの優れた はるかに明確な説明があるサイト があります。