この記事では、主に、設計パターンの概念、分類、基本要素、利点、およびその他の設計パターンの機能を紹介し、Java Editionの「設計パターン」列で各設計パターンのブログの基礎を築きます。
オブジェクト指向の設計原則：https : //blog.csdn.net/qq_34896730/article/details/105352240
1.デザインパターンとは
デザインパターン（デザインパターン）は、繰り返し使用されるセットです。ほとんどの人は、カタログ化、コードデザインエクスペリエンスの概要の後で、デザインパターンを使用することで、再利用可能なコードを他のユーザーがより簡単に理解し、コードの信頼性を向上させることを知っています。設計パターンは、ソフトウェアシステムで常に発生する設計問題の解決策を文書化するための手法であり、専門家の設計経験を共有するための手法でもあります。
1991年から1992年まで「Gang of Four（GoF、Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides）」と名乗った4人の有名なソフトウェアエンジニアリング学者ソフトウェア開発でより頻繁に使用される設計パターンは、パターンを使用して、分析、設計、およびオブジェクト指向メソッドの実装の間のギャップを統一することを目的としています。
GoFは、次のように設計パターンを定義します。
設計パターンは、特定の環境での一般的なソフトウェア設計問題を解決するための一連のカスタマイズされたソリューションであり、オブジェクトとクラス間の相互作用を記述します。
2.デザインパターンの基本要素
設計パターンには、通常、パターン名、問題、目的、解決策、効果、サンプルコード、および関連する設計パターンが含まれます。主要な要素は次の4つです。
1.パターン名（パターン名）
パターン名は、1つまたは2つの単語でパターンの問題、解決策、および効果を説明します。パターンをよりよく理解し、開発者間のコミュニケーションを容易にするために、ほとんどのパターンはその機能に基づいていますまたはモデルの結果。デザインパターンを学習するときは、最初にパターンの中国語と英語の名前を正確に覚えておく必要があります。既存のクラスライブラリでは、通常、デザインパターンを使用するクラス名の多くに、使用するデザインパターンの名前が含まれています。クラスのクラス名がXXXAdapter、このクラスはアダプタークラス、アダプターパターンは設計時に使用されます。クラスのクラス名がXXXFactoryの場合、クラスはファクトリクラスであり、クラスのインスタンスオブジェクトを返すためのファクトリメソッドを含む必要があります。
2.問題（問題）
問題は、モードをいつ使用する必要があるかを説明するもので、設計の問題と問題の理由が含まれています。これらの問題のいくつかは、オブジェクトを使用して状態をカプセル化する方法やオブジェクト表現アルゴリズムを使用する方法など、特定の設計上の問題です。または、システムに柔軟性のないクラスまたはオブジェクト構造があり、システムの保守性が低下する場合があります。場合によっては、パターンの問題の説明セクションに、パターンを使用するときに満たす必要がある一連の前提条件が含まれていることがあります。たとえば、ブリッジモードを使用する場合は、システムに2つの独立して変化するクラスの次元が必要であり、結合モードを使用する場合は、全体と部分の階層が存在する必要があります。問題を説明しながら、実際にパターンに対応する環境とパターンを使用する動機を決定します。
3.ソリューション
ソリューションでは、設計パターンのコンポーネント、およびこれらのコンポーネント間の相互関係、責任、コラボレーションの方法について説明します。パターンは汎用的なテンプレートです。パターンはさまざまな場面で使用できます。このソリューションでは、特定の特定の設計と実装については説明していませんが、設計問題の抽象的な説明と、一般的に重要な要素の組み合わせの使用方法を提供しています（クラスとオブジェクトの組み合わせ）この問題を解決するには、ユーザーはクラス図を習得し、クラス図の各役割の意味とそれらの間の関係を理解し、実際の開発を容易にするためにパターンを実装するコアコードを習得する必要がありますデザインパターンを合理的に適用します。
4.効果（結果）
効果は、モードの適用の効果と、モードを使用する際に考慮すべき問題について説明します。効果には主にモデルの利点と欠点の分析が含まれます。100％完全なソリューションはなく、設計モデルを使用する場合は合理的な評価と選択が必要であることを知る必要があります。モデルにはいくつかの側面で利点があり、別の側面では欠陥があるかもしれませんが、モデルの影響を包括的に検討する必要があります。効果を評価するときは、パターンが単一責任の原則に準拠しているかどうか、またはパターンが開閉の原則に準拠しているかどうかを判断するなど、オブジェクト指向の設計原則を通じて分析します。
上記の4つの基本要素に加えて、完全な設計パターンの説明には、通常、パターンのエイリアス（他の名前）、パターンの分類（パターンが属するカテゴリ）、およびパターンの適用性（設計パターンを使用できる場合）が含まれます。 、パターンの役割（つまり、パターン参加者、パターン内のクラスとオブジェクト、およびそれらの間の責任）、パターンインスタンス（例を使用してパターンの理解をさらに深める）、パターンアプリケーション（既存のシステムでのパターンの使用） 、モード拡張（このモードに対するいくつかの改善、それに関連する他のモード、および他の拡張知識）など
3.設計パターンの分類
デザインパターンには、2つの一般的な分類方法があり
ます。1.目的に応じた分類
デザインパターンは、目的（パターンの用途）に応じて、クリエイティブ、構造、および動作の3つのタイプに分類できます。
（1）作成モードは主にオブジェクトの作成に使用され、GoFには、ファクトリーメソッド、抽象ファクトリー、ビルダー、プロトタイプの5つの作成モードがあります。 ）シングルトンモード（シングルトン）。
（2）構造モードは、主にクラスまたはオブジェクトの組み合わせを処理するために使用されます。GoFは、アダプターモード（アダプター）、ブリッジモード（ブリッジ）、組み合わせモード（複合）、デコレーションモード（デコレーター）の7つの構造モードを提供します、外観モード（Facade）、フライエレメントモード（Flyweight）、プロキシモード（Proxy）。
（3）動作モードは主に、クラスまたはオブジェクトがどのように相互作用するか、および責任を割り当てる方法を説明するために使用されます。GoFは、11の動作モード、つまり責任の連鎖、コマンドモード、およびインタープリターモード（インタープリター、イテレーター、メディエーター、メメント、オブザーバー、状態、戦略、テンプレートメソッド、訪問者モード（訪問者）。
2.スコープ分類
設計モードによるスコープによる（つまり、モードは主にクラス間の関係またはオブジェクト間の関係を処理するために使用されます）、2つのタイプに分類できます：クラスモードとオブジェクトモード。
（1）クラスモデルは、クラスとサブクラス間の関係を処理します。これらの関係は、継承によって確立され、コンパイル時に決定されます。これは静的な関係です。
（2）オブジェクトモデルはオブジェクト間の関係を処理します。これらの関係は実行時に変化し、より動的です。
4. GoFデザインパターンの概要
合計23のデザインパターンは、GoFのクラシックブック「デザインパターン：再利用可能なオブジェクト指向ソフトウェアの基礎」に記載されており、これらの23パターンがそれぞれ表1に示されています。
| 範囲/目的 | 作成モード | 構造モデル | 行動モデル |
|---|---|---|---|
| クラスパターン | ファクトリーメソッドパターン | （クラス）アダプターモード | 解釈パターン テンプレートメソッドパターン |
| オブジェクトモード | 抽象ファクトリパターン ビルダーパターン プロトタイプパターン シングルトンパターン |
（オブジェクト）アダプタモード ブリッジモード コンビネーションモード デコレーションモード アピアランスモード フライオーバーモード プロキシモード |
責任の連鎖パターン コマンドパターン イテレーターパターン メディエーターパターン メモパターン オブザーバーパターン ステータスパターン 戦略パターン ビジターパターン |
| モードカテゴリ | モード名 | モードの説明 |
| クリエイティブパターン | 抽象ファクトリパターン | 特定のクラスを指定せずに、一連の関連または相互依存オブジェクトを作成するためのインターフェースを提供する |
| ビルダーパターン | 複雑なオブジェクトの構築をその表現から分離して、同じ構築プロセスで異なる表現を作成できるようにする | |
| ファクトリメソッドパターン | オブジェクトを作成するためのインターフェースを定義しますが、インスタンス化するクラスはサブクラスに決定させます。ファクトリメソッドパターンは、クラスのサブクラスへのインスタンス化を遅らせます | |
| プロトタイプパターン | プロトタイプインスタンスを使用して作成するオブジェクトのタイプを指定し、このプロトタイプを使用して新しいオブジェクトを作成します | |
| シングルトンパターン | クラスのインスタンスが1つだけであることを確認し、この一意のインスタンスにアクセスするためのグローバルアクセスポイントを提供します | |
| 構造パターン | アダプターパターン | あるクラスのインターフェースを、顧客が望む別のインターフェースに変換します。アダプター・パターンにより、互換性のないインターフェースを持つクラスが一緒に機能することができます |
| ブリッジパターン | 抽象部分と実装部分を分離して、両方が独立して変更できるようにする | |
| 複合パターン | 複数のオブジェクトを組み合わせてツリー構造を形成し、部分全体の関係を持つ階層構造を表します。結合モードにより、クライアントは単一のオブジェクトと結合されたオブジェクトを均一に処理できます | |
| デコレータパターン | オブジェクトにいくつかの追加の責任を動的に追加します。拡張機能の観点から、装飾パターンはサブクラスを使用するよりも柔軟な代替手段を提供します | |
| ファサードパターン | サブシステム内のインターフェースのグループに統一された入り口を提供します。外観モードは、このサブシステムを使いやすくする高レベルのインターフェースを定義します | |
| フライウェイトパターン | 共有テクノロジーを使用して、多数の細粒度オブジェクトの再利用を効果的にサポートする | |
| プロキシパターン | オブジェクトのプロキシまたはプレースホルダー、および元のオブジェクトへのアクセスを制御するプロキシオブジェクトを提供する | |
| 行動パターン | 責任パターンのチェーン | リクエストの送信側と受信側の結合を避け、複数のオブジェクトをチェーンに接続し、オブジェクトが処理できるようになるまでチェーンに沿ってリクエストを渡します。 |
| コマンドパターン | リクエストをオブジェクトとしてカプセル化します。これにより、さまざまなリクエストを使用して、クライアントのパラメータ化、リクエストのキューへの登録、またはリクエストログの記録、および可逆操作のサポートが可能になります。 | |
| 通訳パターン | 言語を指定して、その文法の表現を定義し、その表現を使用して言語の文を解釈するインタープリターを定義します | |
| イテレーターパターン | オブジェクトの内部表現を公開せずに、集約オブジェクトの各要素に順次アクセスするメソッドを提供します | |
| メディエーターパターン | オブジェクトを定義して、一連のオブジェクトの相互作用をカプセル化します。中間モデルでは、各オブジェクトを明示的に相互に参照する必要がないため、疎結合であり、オブジェクト間の相互作用を個別に変更できます。 | |
| メメントパターン | カプセル化を破棄せずにオブジェクトの内部状態をキャプチャし、この状態をオブジェクトの外部に保存して、後でオブジェクトを元の保存された状態に復元できるようにする | |
| オブザーバーパターン | オブジェクト間の1対多の依存関係を定義します。これにより、オブジェクトの状態が変化するたびに、その関連する依存オブジェクトに通知され、自動的に更新されます。 | |
| 状態パターン | 内部状態が変化したときにオブジェクトの動作を変更できるようにします。オブジェクトはクラスを変更しているようです | |
| 戦略パターン | 一連のアルゴリズムを定義し、各アルゴリズムをカプセル化して、他のアルゴリズムが互いに置き換えられるようにします。戦略モデルにより、アルゴリズムを使用する顧客から独立してアルゴリズムを変更できます | |
| テンプレートメソッドパターン | 操作でアルゴリズムのフレームワークを定義し、サブクラスへのいくつかのステップを遅らせます。テンプレートメソッドパターンを使用すると、サブクラスは、アルゴリズムの構造を変更せずに、アルゴリズムの特定の特定のステップを再定義できます。 | |
| 訪問者パターン | オブジェクト構造の各要素に作用する操作を表します。訪問者パターンは、各要素のクラスを変更せずに、これらの要素に新しい操作を定義できます | |
5.デザインパターンの利点
設計パターンは、多くの優れたソフトウェアシステムからの保守性と再利用によって達成できる成功した設計計画です。これらの計画を使用すると、繰り返し作業を行う必要がなくなり、高品質のソフトウェアシステムを設計できます。具体的には、デザインパターンの利点は次のとおりです。
(1) 设计模式融合了众多专家的经验，并以一种标准的形式供广大开发人员所用，它提供了一套通过的设计词汇和一种通用的语言以方便开发人员之间沟通和交流，使得设计方案更加通俗易懂。对于使用不同编程语言的开发和设计人员可以通过设计模式来交流系统设计方案，每一个模式都对应一个标准的解决方案，设计模式可以降低开发人员理解系统的复杂度。
(2) 设计模式使人们可以更加简单、方便地复用成功的设计和体系结构，将已证实的技术表述成设计模式也会使新系统开发者更容易理解其设计思路。设计模式使得重用成功的设计更加容易，并避免那些导致不可重用的设计方案。
(3) 设计模式使得设计方案更加灵活，且易于修改。在很多设计模式中广泛使用了开闭原则、依赖倒转原则、迪米特法则等面向对象设计原则，使得系统具有较好的可维护性，真正实现可维护性的复用。在软件开发中合理地使用设计模式可以使系统中的一些组成部分在其他系统中得以重用，而且在此基础上进行二次开发很方便。正因为设计模式具有该优点，所以在JDK、Struts、Spring、Hibernate、JUnit等类库和框架的设计中大量使用了设计模式。
(4) 设计模式的使用将提高软件系统的开发效率和软件质量，并且在一定程度上节约设计成本。设计模式是一些通过多次实践得以证明的行之有效的解决方案，这些解决方案通常是针对某一类问题最佳的设计方案，因此可以帮助设计人员构造优秀的软件系统，并可以直接重用这些设计经验，节省系统设计成本。
(5) 设计模式有助于初学者更深入地理解面向对象思想，一方面可以帮助初学者更加方便地阅读和学习现有类库与其他系统中的源代码，另一方面还可以提高软件饿设计水平和代码质量。
