Pythonのような動的言語では不要なデザインパターンはありますか？
GoFのデザインパターンブックを読み始めました。いくつかのパターンは非常に似ているように見えますが、概念的な違いはわずかです。
Pythonのような動的言語では、いくつかは不要な多くのパターンから考えますか（たとえば、それらは動的機能に置き換えられているため）？
Peter Norvigは、GOFブックにある23のデザインパターンのうち16が 動的言語では目に見えないか、より単純 （LISPとDylanに焦点を当てている）であることを示しています。
Pythonについて触れたので、このトピックについては、Nice presentation がAlex Martelliによって作成されています。また、Pythonに関連して、 慣用的なPythonの6つのデザインパターン を示すニースのブログ投稿があります。
Pythonで最も一般的なデザインパターン の実装（他の人による）を備えたgithubリポジトリも保持しています。
デザインパターンは必要ありません。どの言語でも
私は、デザインパターンをよく読んでから、どこでもそれらを使用する必要があると考える人々によって書かれた多くのコードに遭遇する傾向があります。その結果、実際のコードは大量のインターフェース、ラッパー、レイヤーの下に埋もれてしまい、非常に読みにくくなっています。これは、設計パターンに対する間違ったアプローチです。
問題に遭遇したときに便利なイディオムのレパートリーが手元にあるように、デザインパターンが存在します。ただし、問題を特定する前にパターンを適用しないでください。 Keep It Simple Stupidは常に優れた統治原則である必要があります。
また、特定の定型コードを記述するのではなく、問題を考えるための概念として設計パターンを考えることも役立ちます。 Javaの回避策としてのボイラープレートの大部分は、PythonやC＃、C++などのような他のほとんどの言語で使用する無料の関数や標準関数オブジェクトが不足しています）。
私はビジターパターンを持っていると言うかもしれませんが、ファーストクラスの関数を持つ任意の言語では、それは関数をとる関数にすぎません。ファクトリクラスの代わりに、私は通常、ファクトリ関数だけを持っています。私はインターフェースを持っていると言うかもしれませんが、それは他の実装がないため、コメントでマークされたいくつかのメソッドです（もちろんpythonなぜなら、それはそれを考えるのに役立つ方法だからです。しかし、本当に必要になるまで、すべてのものを実際に入力しないでください。
allパターンをconceptsとして学習します。そして、特定の実装を忘れてください。実装はさまざまであり、Javaだけでも、現実の世界では変わるはずです。
Abstract factory pattern は、Pythonなどのダック型言語では、実際に組み込まれているため不要です。
頭に浮かぶのは、シングルトンパターンだけです。
Pythonはeverythingのクラスを使用することを強制しないため、代わりにグローバルデータ構造を使用できます。そのグローバルデータ構造could =インスタンスによって管理されますが、そのクラスのインスタンス化を制御する必要はありません。インポート時にインスタンスを作成し、そのままにしておきます。
ほとんどの場合、pythonのシングルトンはモジュールに置き換えられます。pythonのモジュールは、その性質上シングルトンです。pythonインタプリタはこれらを一度だけ作成します。
Python=で一度に使用したデザインパターのその他すべてのパターン、およびPython標準ライブラリ全体でそれらの例が見つかります。 Python自体。
デザインパターンは、言語用ではなくプログラマ用です。プログラマーは、目の前の問題を理解するのに役立つパターンを使用する傾向があります。厳密に必要なデザインパターンはありませんが、実行しようとしていることを単純化するのに役立つ場合があります。
Python、そして特にダックタイピングは、多くの一般的なパターンと実践の周りに終わりをもたらし、いくつかのパターンによってもたらされる多くの制限（プライバシー、不変性など）は、プログラマーがそれらを破らないことに同意する範囲でのみ保持されます。しかし、それでも、プログラマが一緒にプレイしている限り、doは機能します。架空の壁で囲まれていても、ドアはドアです。
Pythonは「マルチパラダイム」言語と見なされています。好きなパターンを使うことができます。これは意図的なものです。たとえば、完全に不要で少し人工的なものであるにもかかわらず、複雑なクラス階層を提供します。しかし、特定の抽象化が役立つ人もいます。問題がそれを要求するからではなく、プログラマーが要求するからです。さあ、行きます。
オリジナルの「デザインパターン」の本は、C++やSmalltalkなどの命令型オブジェクト指向言語で役立つ一般的なイディオムを文書化して名前を付けたものです。しかし、Smalltalkは動的に型付けされた言語なので、厳密に動的であることは問題になりません。
ただし、あなたの質問に対する答えはまだ「はい」です。これらの設計パターンの一部は、最新の動的型付け言語とは無関係です。より一般的には、異なる言語、特に異なる種類の異なる設計パターンがあります。
繰り返しますが、「デザインパターン」は、プログラミングイディオムの単なる名前であり、頻繁に発生する問題の一般的な解決策です。ある言語の問題は別の言語にとっては些細なことかもしれないので、異なる言語には異なるイディオムが必要です。この意味で、デザインパターンは、適用される言語の弱点を指摘する傾向があります。
したがって、現代の動的言語（またはLISPのような古代言語）をより強力にし、これらの古典的な設計パターンのいくつかを無関係にする他の機能を探すかもしれません。
デザインパターンは、特定の問題を解決する方法です。問題が解決しない場合、それを解決するパターンは役に立ちません。
人々は、あたかもプロジェクトにデザインパターンを含めることがベストプラクティスであるかのように、あらゆる場所でデザインパターンを適応させようとしています。それは別の方法です。ファクトリーパターンで解決できる問題が発生しましたか？涼しい。それを適応させます。コードを調べて、シングルトン（またはファクトリー、ファサードなど）を実装する適切な場所を見つけようとしないでください。
おそらくPythonにはJavaおよび.NETの人々（これらの言語の性質のため）には利用できない独自の設計パターンがあります）？
パターンは常に言語に依存すると私は言うでしょう。ほとんどのpythonパターンはGoFで定義されているパターンのように見えます。これは、PythonのOOPという理由で、OOPがOOPのようなものではありません（2つの言語でオブジェクトとその操作を100％定義している言語はありません）。
したがって、一部のパターンは「現状のまま」適用できないことに疑いの余地はありません。一部のパターンは意味をなさない可能性があり、Pythonにとってのみ意味があるかもしれないいくつかのパターンがあります。
質問に正確に戻るには、パターンが必要な場合必要な場合のみです。必要がない場合は、使用する必要はありません（Jan Hudecがすでに言ったように）。
さらに、GoFで言及されているパターンよりもはるかに多くのパターンがあります。ウィキペディアで参照 その他のパターン