Pythonのような動的言語で不要なデザインパターンはありますか？

GoFがデザインパターンブックを読み始めました。いくつかのパターンは非常に似ているように見えますが、概念的な違いはわずかです。

Pythonなどの動的言語では不要なパターンがいくつかあると思いますか（たとえば、動的機能に置き換えられるため）。

Peter Norvigは、GOFの本で見つかった23のデザインパターンのうち16 が動的言語では見えないか、より単純であることを実証しています（彼はLispとDylanに焦点を当てています）。

Pythonについて言及したので、Alex Martelliによるこのトピックに関する素晴らしいプレゼンテーションがあります。また、Pythonに関連して、慣用的なPythonの6つの設計パターンを示す素晴らしいブログ投稿があります。

また、Pythonで最も一般的なデザインパターンの実装（他の人による）とともにgithubリポジトリを保持しています。

デザインパターンは必要ありません。どの言語でも。

私は、デザインパターンを読んで、それをあちこちで使うべきだと思う人々によって書かれた多くのコードに出くわす傾向があります。その結果、実際のコードは大量のインターフェース、ラッパー、レイヤーに埋もれてしまい、読みにくくなります。それはデザインパターンに対する間違ったアプローチです。

問題に遭遇したときに便利なイディオムのレパートリーが手元にあるように、デザインパターンが存在します。ただし、問題を特定する前にパターンを適用しないでください。シンプルに保つバカは常に優れた統治原則であるべきです。

また、設計パターンを、記述する特定の定型コードではなく、問題について考える概念として考えると役立ちます。また、Javaの回避策としてのボイラープレートの多くは、無料の関数と、それらを使用する他のほとんどの言語（Python、C＃、C ++など）で使用する標準関数オブジェクトを欠いています。

私はビジターパターンを持っていると言うかもしれませんが、ファーストクラスの関数を持つすべての言語では、関数をとる関数になります。ファクトリクラスの代わりに、通常はファクトリ関数のみを持っています。私はインターフェースを持っていると言うかもしれませんが、それは他の実装がないため、コメントでマークされたいくつかのメソッドです（もちろん、Pythonではインターフェースは常にダックタイプであるため、単にコメントです）。私はまだパターンを使用するコードについて話します。それはそれを考えるのに便利な方法だからです。しかし実際に必要になるまですべてを入力しないでください。

したがって、すべてのパターンを概念として学びます。そして、特定の実装を忘れてください。実装はさまざまであり、現実の世界では、Javaでさえさまざまです。

Pythonなどのアヒル型言語では、実際に言語に組み込まれているため、抽象ファクトリパターンは不要です。

頭に浮かぶのは、シングルトンパターンだけです。

Pythonはすべてにクラスを使用することを強制しないため、代わりにグローバルデータ構造を使用することができます。そのグローバルデータ構造はインスタンスで管理できますが、そのクラスのインスタンス化を制御する必要はありません。インポート時にインスタンスを作成し、そのままにしておきます。

ほとんどの場合、Pythonのシングルトンはモジュールに置き換えられます。Pythonのモジュールは、本質的にシングルトンです。Pythonインタプリタはこれらを一度だけ作成します。

私がPythonで使用したデザインパターンの他のすべてのパターンは、Python標準ライブラリ全体およびPython自体で使用されています。

設計パターンはプログラマー向けであり、言語向けではありません。プログラマーは、目前の問題を理解するのに役立つパターンを使用する傾向があります。設計パターンは厳密には必要ありませんが、やろうとしていることを単純化するのに役立つかもしれません。

Python、特にカモタイピングは、多くの一般的なパターンと慣行の終わりを提供し、いくつかのパターン（プライバシー、不変性など）によって課せられた多くの制限は、プログラマがそれらを壊さないことに同意する範囲でのみ保持します。しかし、まだ、彼らがない限り、プログラマが一緒に果たしているとして働いています。ドアは、たとえ想像上の壁で囲まれていても、依然としてドアです。

Pythonは「マルチパラダイム」言語と見なされます。好きなパターンを使用できます。これは意図的なものです。たとえば、完全に不要で少し人工的なものであるにもかかわらず、複雑なクラス階層を提供します。しかし、一部の人々にとっては、特定の抽象化が役立つことです。問題がそれを要求しているからではなく、プログラマが要求しているからです。それであなたは行き​​ます。

オリジナルの「デザインパターン」の本は、C ++やSmalltalkなどの命令型のオブジェクト指向言語で役立ついくつかの一般的なイディオムを文書化し、命名しました。しかし、Smalltalkは動的に型付けされた言語であるため、厳密に動的であるということはできません。

ただし、あなたの質問に対する答えは依然として「はい」です。これらのデザインパターンの一部は、現代の動的に型付けされた言語とは無関係です。より一般的には、異なる言語、特に異なる種類の言語では、異なる設計パターンが存在します。

繰り返しになりますが、「設計パターン」とは単にプログラミングのイディオムの名前であり、頻繁に発生する問題の一般的な解決策です。言語ごとに異なるイディオムが必要です。1つの言語の問題は別の言語では些細なことかもしれないからです。この意味で、設計パターンは、適用する言語の弱点を指摘する傾向があります。

したがって、現代の動的言語（またはLispのような古代の言語）をより強力にし、これらの古典的なデザインパターンのいくつかを無関係にする他の機能を探すかもし​​れません。

デザインパターンは、特定の問題を解決する方法です。問題が満たされない場合、それを解決するパターンは役に立ちません。

人々は、プロジェクトにデザインパターンを含めることがベストプラクティスであるかのように、デザインパターンをあらゆる場所で適応しようとしています。それは別の方法です。工場出荷時のパターンで解決できる問題が発生しましたか？クール。それを適応させます。コードを調べて、シングルトン（またはファクトリー、ファサード、その他）を実装する適切な場所を見つけようとしないでください。

おそらくPythonには、Javaと.NETの人々には利用できない独自のデザインパターンがあります（これらの言語の性質のため）？

パターンは常に言語に依存していると思います。ほとんどのpythonパターンはGoFで定義されたもののように見えますが、それはPythonのOOPのためです。

そのため、一部のパターンは「そのまま」適用できず、一部は意味をなさない可能性があり、Pythonにとってのみ意味のあるパターンもあります。

あなたの質問に正確に戻って取得するには：あなたがいる場合のパターンにのみ必要です必要にそれらを。それらの必要がない場合は、それらを使用する必要はありません（Jan Hudecが既に述べたように）。

さらに、GoFで言及されているものよりもはるかに多くのパターンがあります。ウィキペディアで他のパターンを見る