パンをスライスして以来、デザインパターンが最高のものであると主張したと聞いています。また、デザインパターンは「セカンドシステムシンドローム」を悪化させる傾向があり、非常に使い古されており、ユーザーに実際よりも優れたデザイナーだと思わせると主張していると聞きました。
私は以前のキャンプに近づく傾向がありますが、最近では、ほぼすべての相互作用がオブザーバー関係に置き換えられ、すべてがシングルトンであるデザインを見てきました。
それでは、利点と問題を考慮して、設計パターンは一般に良いか悪いか、そしてその理由は何ですか？
回答:
設計パターンは言語であり、プログラムや契約書を書くためのアドバイスではありません。それらの主な用途は、コンポーネントまたはシステムがどのように実装された（または実装される予定であるか）事後説明です。細部にこだわる代わりに、リスナーがそれがどのように機能し、何が重要であるかを理解するのに十分な実装を説明できるいくつかの言葉を言うことができます。
Alex：ねえ、構成ファイルはどのように作成されますか？
Bob：それらはにあるファクトリによって生成されます
config.h。
これでアレックスは、構成ファイルの作成に重要な準備が必要であることを知っています。そうしないと、作成が工場に囲まれないからです。
ただし、Bobがパターン指向の偽物であり、あちこちでパターンを使用している場合、Bobは工場をどこでも使用しているため、構成の作成について何も伝えることができませんでした。これは、プログラムの過度の複雑さにもつながります。
したがって、最初にプログラムを作成してから、コード内のパターンを見つけてください。それが効果的な使い方です。
デザインパターンは素晴らしいです。適切に使用すると、コードのメンテナンス性が向上し、読みやすくなり、作業しやすくなります。優れたプログラマーになるには、停止するタイミングを知って、それ以上のリファクタリングがメリットを上回ることを確認する必要があります。設計パターンを単独で使用しても、誰かが優れたプログラマーになるわけではありませんが、いつ、どこでそれらを使用するかを知っています。この世界の他のものと同じように、デザインパターンは極端になり、悪用される可能性があります。すべてのデザインパターンに目的があり、ジグソーパズルのピースのように完全に所定の位置に収まるコードの完璧なバランスを、私はまだ探しています（そして、長い間そうするでしょう）。
設計パターンは、正しく使用すれば素晴らしいです。
設計パターンのアイデアはアーキテクチャに由来することを覚えておくと便利です。アーキテクチャは大きく異なります。しかし、どの建物にも多くのコアアイデアがあります。このように、パターンはデザインの構成要素と考えてください。すべての建物にすべての可能なアーキテクチャパターンが含まれているわけではないことに注意することが重要です。
あなたが家を設計しているとしましょう。正面玄関を通りに開けるのではなく、家に入る前に保護された場所、すなわち控え室が必要です。この領域は特定のパターンに適合します。つまり、2つの入り口、いくつかの壁、そしておそらく屋根があります。このパターンは、ドア、窓、または壁の数を指定しないことに注意してください。ほとんどの実装では、2つのドア、4つの壁、そしておそらく窓があります。ただし、このパターンは、2つの入り口がある囲まれた領域を示しています。1つは家の外から控え室自体につながり、もう1つは家の残りの部分につながります。ここで重要なのは、控え室が必要な場合は、エリアを囲み、そのエリアへの2つの入り口を提供する必要があるということです。
プログラミングにおける設計パターンの典型的な問題は使いすぎであり、問題を解決するための特効薬であるという信念です。ではない。それらは、有用なプログラミングのアイデアを伝え、考える方法です。特定の言語の構文の一部がレンガとモルタルである場合、パターンは特定のニーズを満たすためにそれらを配置する便利な方法を説明します。
設計パターンは、絶対に従わなければならない不変の契約というよりも、「アドバイス」に近いと考えています。どうして？あなたが言及した理由のために。すべてのデザインパターンに従うことは、最初からパターンを使用する目的に反する大きな混乱を招きます。
これが、Java Practicesのようなサイトが嫌いな理由です。確かにいくつかのアイデアは良いものですが、著者は彼が言及したすべての単一のデザインパターンに従ってプログラム全体（およびフレームワーク）を書くことにしました。著者はまた、実際のJavaの実践は恐ろしく、ペストのように避けるべきだと読者に思わせる大きな怖い引用ですべての記事を書きました。
TL; DR：デザインパターンを使用します。悪用しないでください
SOでこのスレッドも参照してください。別のPOV設計パターンには、使用される方法論の欠点を補う定型コードがあります。私はこれらの回避策をあまりにも祝うのが好きではありません。
私は真ん中のものを好むでしょう。正しく指摘されたポスターのように、パターンを理解しても良い開発者にはなりません。一方、パターンを理解することは、優れた開発者になるのに役立ちます。
パターンの関係を理解し、プロジェクトのパターンを（構想段階で）見ることが、優れた開発者となるでしょう。
設計パターンは、プログラミングの問題に対する既成のソリューションを提供するとよく言われます。それらはどのような問題ですか？「どうすればオブジェクトの動作を変更できますが、システムの他の部分から変更を分離できますか？」
GoFパターンは、システムの他の部分からの分離（カプセル化）を提供することで認識されていますが、システムのどの部分に設計パターンを使用して変動性が与えられているかを知ることはしばしば困難です。彼らが提案した分類スキーム（創造的、行動的、構造的）に従う代わりに、パターンの違いを図表化し、パターンを分類するためにライフサイクルとコンポーネントカプセル化階層の2つのスキームを考え出しました。
カプセル化階層のこの表からわかるように、設計パターンはコンポーネントのすべてのレベルに適用できます。しかし、それは理にかなっていますか？コンポーネントは、提案されたカプセル化レベルで動作の変化を提供する必要があり、そのレベルに適切なパターンが使用されていますか？これらの質問が適切に回答されない場合、デザインパターンが誤って適用される可能性が高くなります。車のキャビンに垂直ピボットを組み込むことができたからといって、それを賢明なアイデアとはしません。
お金との類似性を使用すると、設計パターンは、資本コストは高くても運用コストは低いソリューションと考える必要があります。設計パターンは、余分なコーディング、冗長性、およびそれらが作成する余分な間接性からの概念的な重みという点で、前払いで費用がかかります。また、デザインの他の側面をロックダウンする傾向があります。たとえば、テンプレートメソッドを使用すると、強制的にオブジェクト指向スタイルでプログラミングする必要があります。
ただし、いくつかの小さな方法で変化する多くの密接に関連する問題を解決する必要がある場合、または将来特定の方法でコードの一部を大幅に変更する必要がある場合は、設計のために初期費用が価値がある可能性がありますパターンはコードに柔軟性を追加します。密接に関連する一連の問題の2番目の修正または解決策は、パターンを使用するよりも使用しないよりもはるかに簡単になります。
デザインのダッターは、コードに常に適用しようとしているものではないと思います。私にとっては、主に開発者向けの共通言語についてです。全体を何度も説明するよりも、「ビルダーパターンに従う」と言う方が簡単です。
私は現在、エンタープライズアプリケーションアーキテクチャのパターンを読み直しています。なぜなら、その本のパターンの1つに従う多くのコードに出くわしたからです。パターンの1つに従うように意図的に選択されたとは思いませんが、「トランザクションスクリプト」と言うことができ、誰もがその意味を明確に理解していると間違いなく役立ちます。
しかし、新しい機能やまったく新しいアプリケーションを設計するときに、用意されているパターンのカタログから選択できるというアイデアが気に入っています。特定の問題に対する実証済みのソリューションがある場合、なぜすべてを再発明するのですか？