最悪または最も狭く定義されているデザインパターンはどれですか。
すべてのプログラミングプロジェクトで、過去のプログラミング経験を持つマネージャーは、プロジェクトにいくつかの設計パターンを推奨するときに輝きます。デザインパターンが理にかなっている場合や、スケーラブルなソリューションが必要な場合に、私はデザインパターンが好きです。たとえば、プロキシ、オブザーバー、コマンドパターンをポジティブな方法で使用し、毎日使用しています。ただし、オブジェクトを作成する方法が1つしかない場合、ファクトリーを使用するとファクトリーが将来すべてが容易になる可能性がありますが、コードが複雑になり、純粋なオーバーヘッドになるため、ファクトリーパターンを使用するのは非常に躊躇しています。
だから、私の質問は私の将来のキャリアと、ランダムなパターン名を投げるマネージャーのタイプに対する私の答えです：
どのデザインパターンを使用しましたか？ 最悪のデザインパターンはどれですか、それらが意味を持つ単一の状況を除いて考慮する必要があるもの（読み取り：非常に狭義に定義されているデザインパターン）？ （私がAmazonの全体的に良い製品の否定的なレビューを探していて、デザインパターンを使用するときに最もバグの多い人を探していたようです。）ここでは、アンチパターンについてではなく、通常は次のように考えられているパターンについて話しています。 「良い」パターン。
編集：一部の人が回答したように、問題はほとんどの場合、パターンが「悪い」ではなく「間違って使用されている」ことです。よく誤用されたり、使用するのが難しいパターンを知っている場合は、回答としても当てはまります。
私は悪いパターンを信じていません。パターンがうまく適用されないと信じています。
- IMHO シングルトン は、最も悪用され、最も誤って適用されたパターンです。人々はシングルトン病にかかり、代替案を考慮せずにどこにでもシングルトンの可能性を見始めているようです。
- IMHO 訪問者パターン の用途は最も狭く、追加された複雑さが正当化されることはほとんどありません。素敵なpdfを入手できます here 。実際に、事前にすべての方法を知らなくても、データ構造でさまざまな操作を実行しているときにトラバースされることがわかっているデータ構造がある場合にのみ、ビジターパターンに戦いの機会を与えます。それはかなりです:)
この回答では、GOFパターンのみを検討しました。考えられるすべてのパターンを十分に理解しているわけではありません。
私はここで外に出て、継承の過剰使用を提案します。 Javaのように、コンパイル時の確実なポリモーフィズムがサポートされていない言語で間違いなく最も適切です。実行時の継承はツールであり、1つの機能ですべてに対応できるなんてことはありません。
他の人々はすでに私の個人的なシングルトンへの憎しみに似た表現をしているので、ここではそれについて詳しく説明しません。
他の回答者が既に述べたシングルトンとビジターは別として、「悪名高い」デザインパターンについては知りません。私見最大の問題は、特定のデザインパターンが「間違っている」ことに起因するのではなく、パターンをあまりにも熱心に適用している開発者に起因しています。
パターンに慣れると、ほとんどの人が「パターンフィーバー」フェーズを経験します。スライスされたパン以来、パターンは最良のものであると考え、最初は可能性を見つけたときはいつでもそれらを適用しようとします。その結果、コードがパターンの下に埋もれてしまい、パターン自体が役に立たなくなり、長期的にコードを理解および維持することが難しくなります。
最終的に、私たちのほとんどはこのフェーズを乗り越えて、自分のためではなく、パターンを使用して実際の問題を解決する方法を学び始めます。パターンには価格があり、それが複雑さを増します。特定のパターンを適用することは、システムの他の部分を簡略化するのを助けて複雑さを増すことで見返りが得られる場合にのみ正当化され、コード/構成を全体的に理解および維持しやすくします。これが当てはまらない場合は、パターンから離れて、うまくいく可能性のある最も簡単な解決策にこだわる方がよいことがよくあります。
シングルトン。これは、現在はアンチパターンと呼ばれることが多いGOFパターンの一部です。その理由の1つは、シングルトンによりコードのテストが難しくなることです。
Factory。 1つのタイプのみを作成するコードを実装するコードを見ました。それは完全に役に立たないコードIMOです。オンラインの例の多くが完全に考案されていることは役に立ちません。ピザ工場？
おそらく、依存関係の注入により、ファクトリーのテストが容易になります。しかし、必要のないときにそのコードを追加しても意味がありません。また、JMockitのようなモックフレームワークを使用できる場合、テスト引数は消えます。プログラムを簡単に作成できるほど、優れています。ファクトリーが本当に意味をなすのは、より多くのタイプ（大まかに言えば、少なくとも2を超えるタイプ）だけです。
GOFブックのパターンの一部はC++固有です。つまり、リフレクションを使用する言語にはあまり適用されません。 Javaでは、Prototypeパターンはそれほど重要ではありません。
Interpreterパターンは「狭い」パターンと見なします。一般的な問題ソルバーを開発する価値がある一般的な問題が必要です。これは、言語を発明し、文法を定義し、インタープリターを作成できる特別な問題に対してのみ機能します。問題のインスタンスは、文法の文として表現できる必要があります。そのような状況に頻繁に出くわすことはないと思います。
私が最も後悔しているもの（ほとんど激しくはありませんが）：関数を作成する必要があったが、OOPソリューションを実装したとき。
シングルトン
シングルトンについては他の人にも同意します。それらを使用してはならないということではなく、ごく少数のケースに限定する必要があるということだけです。多くの場合、これらは遅延グローバルとして使用されます。
スレッドセーフはシングルトンの1つの問題です。例外処理はもう1つです-シングルトンが適切に作成されない場合-エラーが安全にキャッチできるかどうか、特に「メインの前に」作成されたオブジェクトの1つであるかどうかは常にわかりません。その後、後片付けの問題があります。
私は1つのシングルトンを使用し、他のすべての「ワナビー」シングルトンを「サブスクライブ」して優先する傾向があります。私の最も一般的なシングルトンの使用法は、「シャウトイベント」の処理です。イベントが発生したことを「世界にブロードキャストする」だけで、イベントを処理することを聞いている人なら誰でもそうします。そうすることで、実際に起こっているイベントを、それらを聞いているものと切り離すことができます。 （ロギング、シグナルなど）
訪問者
開発者が意味のある名前を考えることができず、単にメソッドvisit（）を呼び出すことができないという事実は別として、これについて私が見つけた醜いことは、ある方向に拡張性を追加し、別の方向にそれを削除することです。つまり、追加の機能を追加しますが、制限します訪問者が訪問する可能性のあるすべてのオブジェクトタイプについて知る必要があるオブジェクトの数。
面倒ですが、双方向の拡張を許可することは可能ですが、これは通常の形式でビジターパターンを完全に使用するわけではありません。これの最も一般的な用途はオブジェクトの印刷です。オブジェクトを印刷する方法や、印刷する必要のあるオブジェクトはさまざまです。これを両方向に拡張できるはずです。 （印刷とは、オブジェクトをストリームに変換するあらゆる種類のことを意味します：ファイルへの格納/コンソールへの書き込み/ GUIなど）。
（注：これをドキュメントビューアーキテクチャと混同しないでください。これは、少し異なるパターンです）。
より複雑なパターンのいくつかの問題は、それらに非常に多くのバリエーションがあり、通信デバイスとしての価値の多くを失うことです。
このカテゴリで考えられる最悪の犯罪者は、MVCパターンです。 MVPを無視しても、これらの各アイテムの役割には非常に多くのバリエーションがあるため、境界がどこにあるのかを把握するために、新しいフレームワークごとに1時間費やす必要があります。
悪いパターンはなく、悪い人だけです。
私はどちらかと言えば、明確なことをするが少し冗長である（キューイービルビリアンミュージック）再利用可能（ガスプ！）であり、InheritAbstractTemplateFaucetSink<Kitchen>のミッシュマッシュよりも簡単に読みやすいコードを継承します。
再利用可能なコードは素晴らしいです！おそらく、再利用されるコードを記述していないか、別のアプリケーションの同様のロジックを再記述すると、他のアプリケーションのコードを再利用しようとする非常識な試みよりも時間がかかりません。
さらに読むには、posixヘッダーまたはclibの正しい実装でCコードの一部を開いて、パターンを見つけてください。このコードは、世界で最も賢く、最も熱心なプログラマーによって書かれました。いくつの抽象ファクトリパターンが表示されるか知っていますか？ ... なし！。さらに良い可能性は、進行中の他の部分を理解していれば、ロジックを理解して追跡するのが非常に簡単であることがわかるでしょう。
私の要点は、この「パターン」のほとんどは、コードを改善するために作成されたのではなく、本やモデリングソフトウェアを販売するために作成されたということです。プログラミングに長けている場合は、おそらくこれらのほとんどを避け、問題を解決する明確で簡潔で巧妙に設計されたコードを書くでしょう。別の問題がある場合は、その問題を解決するための明確で簡潔な、巧妙に設計されたコードを記述します。あなたの目標が、あなたがプログラマーであるとは限らないと私が思うよりも少ないコードを書くことであるなら。私はコードを書くことが大好きで、できるだけ多くのコードを書きたいと思っています。私がすでに書いたものを書き直すとき、私はそれを数十倍の速さで行い、初めてやったときに不満だったすべてのものを取り除くことができます。おまけとして、新しい問題のため、最初の問題セットの制限なしでそれを行うことができます（おそらく、Tomcatを浮かび上がらせる5つの異なる言語で15のスクリプトがあります）。
以上で、コンピュータサイエンスにおけるおそらく最も適切な（関連する）引用を紹介します。
"ソフトウェア設計を構築するには2つの方法があります。1つは明らかに単純化して欠陥がないようにする方法で、もう1つは複雑化して明らかな欠陥がないようにする方法です。最初の方法はるかに難しいです。 "
- Tony Hoare（クイックソートの発明者、最新のOSデザインの父、Hoareロジックの作成者、およびTuring賞の受賞者）
ほとんどのパターンには時間があり、多くのパターンを乱用する可能性があることは間違いありません。私が過去に最も悪用したのは、抽象テンプレートパターンであることを知っています。 ASP.NET webformsとして知られているその完全な範囲で撮影されました。