ファクトリ クラスを作成し、同じインターフェイスを実装する製品クラスを作成するインターフェイスを定義します。まず関係図を見てください:
(2) ファクトリ メソッド パターン:
ファクトリ メソッド パターンは、シンプル ファクトリ パターンの欠点は、「開閉原則」に準拠していないことです。新しい製品カテゴリが追加されるたびに、ファクトリ クラスを変更する必要があり、拡張や拡張には役立ちません。システムのメンテナンス。ファクトリ メソッドはファクトリを抽象化し、オブジェクトを作成するためのインターフェイスを定義します。新しい製品を追加するたびに、その製品と、対応する特定の実装ファクトリ クラスを追加するだけで済みます。特定のファクトリ クラスは、どの製品をインスタンス化するかを決定し、オブジェクトの作成とサブクラスへのインスタンス化を遅らせます。工場の設計は「開閉原則」に準拠しているため、拡張時に元のコードを変更する必要はありません。 UML 関係図は次のとおりです。
(3) 静的ファクトリ メソッド パターン:
静的ファクトリ パターンは要素を結合します。ファクトリ メソッド パターンではメソッドは静的になるため、インスタンスを作成する必要はなく、直接呼び出すだけです。
ファクトリメソッドパターンの詳細記事：Javaデザインパターンの作成種類：ファクトリパターンの詳細解説（簡易ファクトリファクトリメソッド抽象ファクトリ）
2.作成タイプ - 抽象ファクトリ パターン:
抽象ファクトリ パターンは主に、関連オブジェクトのファミリーを作成するために使用されます。製品ファミリが連携して動作するように設計する必要がある場合、抽象ファクトリ パターンにより、クライアントが常に同じ製品ファミリ内のオブジェクトのみを使用することが保証され、特定のクラスの生成を分離することで、クライアントは特定のクラスを明示的に指定する必要がなくなります。すべての具象ファクトリは抽象ファクトリで定義されたパブリック インターフェイスを実装するため、具象ファクトリのインスタンスを変更するだけで、ソフトウェア システム全体の動作をある程度変更できます。
しかし、このモデルの欠点は、新しい動作を追加するのがより面倒であることです。新しい製品ファミリー オブジェクトを追加する必要がある場合は、インターフェイスとそのすべてのサブクラスを変更する必要があり、必然的にたくさんのトラブル。
UML 構造図は次のとおりです。
抽象ファクトリ パターンの詳細: Java デザイン パターンの作成タイプ: ファクトリ パターンの詳細な説明(単純なファクトリー・ファクトリー・メソッド抽象化ファクトリー)
3. 作成ビルダー・パターン:
ビルダー・パターンは、複雑な製品の作成ステップをさまざまなメソッドに分解し、作成プロセスをより明確にし、したがって、複雑なオブジェクトの構築と使用を分離することによって、つまり、製品の作成を製品自体から分離することで、同じ構築プロセスで異なるオブジェクトを作成できるようにし、各特定のビルダーを使用して、複雑なオブジェクトの生成プロセスをより正確に制御します。相互に相互作用する 独立しているため、コンクリート ビルダーの交換や新しいコンクリート ビルダーの追加が簡単で、ユーザーは異なるコンクリート ビルダーを使用することで、異なる製品オブジェクトを取得できます。 UML 構造図は次のとおりです。
ビルダー パターンの詳細: Java デザイン パターンの作成タイプ: ビルダー パターン
4. 作成タイプ - シングルトン モード:
シングルトン モードでは、システム内に特定のクラスのインスタンスが 1 つだけ存在することが保証されます。クラスは自身をインスタンス化し、このインスタンスのパブリック アクセス ポイントを提供します。システム全体。ただし、このパブリック アクセス ポイントは他の手段ではインスタンスにアクセスできません。シングルトン モードの利点は次のとおりです。
- システム内に存在する共有インスタンス オブジェクトは 1 つだけであり、オブジェクトを頻繁に作成および破棄する必要がないため、システム リソースが節約され、パフォーマンスが向上します。 system.
- クライアントがシングルトン オブジェクトにアクセスする方法とタイミングを厳密に制御できます。
シングルトン パターンを記述する方法はいくつかあります。主に 3 つのタイプがあります。怠け者スタイルのシングルトン、ハングリーマンスタイルのシングルトン、および登録スタイルのシングルトンです。
シングルトン パターンの詳細: Java デザイン パターンの作成型: シングルトン パターン
5. 作成型-プロトタイプ パターン:
プロトタイプ モードはオブジェクトの作成にも使用され、オブジェクトをプロトタイプとして使用し、それをコピーしてクローンすることにより、ソース オブジェクトと同様の新しいオブジェクトが生成されます。 UML クラス図は次のとおりです:
Java では、プロトタイプ パターンの中心となるのはプロトタイプ クラス Prototype です。Prototype クラスは次の 2 つの条件を満たす必要があります。 ##
- Cloneable インターフェイスを実装します:
- オブジェクト クラスの clone() メソッドをオーバーライドして、オブジェクトのコピーを返します。オブジェクトの
clone()クラス デフォルトのメソッドはシャロー コピーですが、オブジェクトをディープ コピーする場合は、 clone() メソッドで独自のコピー ロジックをカスタマイズする必要があります。
- 浅いコピー: オブジェクトをコピーした後、基本データ型の変数が再作成され、参照型は元のオブジェクトが指すメモリ アドレスを指し続けます。
- ディープ コピー: オブジェクトがコピーされた後、基本データ型と参照型の両方が再作成されます。
プロトタイプ モードを使用してオブジェクトを作成すると、オブジェクトの作成手順が簡素化されるだけでなく、新しいメソッドを使用してオブジェクトを作成するよりもパフォーマンスが大幅に向上します。これは、Object クラスの clone() メソッドがローカルメソッドであり、メモリを直接操作します。バイナリストリームでは、特に大きなオブジェクトをコピーする場合、パフォーマンスの違いは非常に明白です。
プロトタイプパターンの詳細: Java デザインパターンの作成タイプ: プロトタイプパターン
上記では 5 つのクリエイティブ モードを紹介しましたが、これからはアダプター モード、デコレーション モード、プロキシ モード、アピアランス モード、ブリッジ モード、コンビネーション モード、およびフライウェイト モードの 7 つの構造モードの紹介を開始します。オブジェクトのアダプター モードは、以下に示すように、さまざまなモードの元になります:
6. 構造アダプター モード:
アダプター モードは主に次のとおりです。クラスやインターフェースをクライアントが望む形式に変換することで、本来互換性のないクラス同士が連携してターゲットクラスとアダプタークラスを切り離すことができると同時に、「開閉原則」にも準拠します。新しいアダプター クラスの追加に基づいて、アダプター クラス内の特定の実装をカプセル化することは、クライアント クラスに対して透過的であり、アダプターの再利用性が向上します。ただし、欠点は、実装がアダプターの交換プロセスは比較的複雑です。
したがって、アダプター モードは、次のシナリオに適しています。
- (1) システムは既存のクラスを使用する必要があり、これらのクラスのインターフェイスは、システムインターフェース。
- (2) サードパーティ製コンポーネントを使用する場合、コンポーネントのインターフェイス定義が独自の定義と異なる場合、独自のインターフェイスを変更したくないが、サードパーティ製コンポーネント インターフェイスの機能を使用する必要があります。 。
次は、アダプター パターンが何であるかを示す非常に鮮明な例です。
アダプター パターンには、主に 3 つの実装があります。アダプタ パターン、オブジェクト アダプタ パターン、インターフェイス アダプタ パターン。 3 つの使用シナリオは次のとおりです。
- クラス アダプター パターン: クラスを別の新しいインターフェイスを満たすクラスに変換する場合、クラス アダプター パターンを使用して新しいインターフェイスを作成できます。元のクラスは新しいインターフェイスを実装できます。
- オブジェクト アダプター パターン: オブジェクトを別の新しいインターフェイスを満たすオブジェクトに変換する場合は、Wrapper クラスを作成し、元のクラスのインスタンスを保持します。Wrapper クラスのメソッドで、インスタンス メソッドで十分です。
- インターフェイスのアダプター パターン: インターフェイス内のすべてのメソッドを実装したくない場合は、抽象クラス Wrapper を作成してすべてのメソッドを実装できます。他のクラスを作成するときは、抽象クラスを継承するだけで済みます。 。
アダプター パターンの詳細: Java デザイン パターンの構造型: アダプター パターン
7. 構造型 - デコレーター パターン:
装飾デコレータ パターンは、関数を拡張するためにオブジェクトに追加の責任を動的に追加したり、実行時に異なるデコレータを選択してさまざまな動作を実現したりできます。継承を使用するよりも柔軟です。さまざまな装飾クラスを配置して組み合わせることにより、さまざまな装飾クラスを作成できます。動作により、より強力な機能を持つオブジェクトが生成されます。「開閉の原則」に従って、装飾クラスと装飾クラスは独立して変化します。ユーザーは、必要に応じて新しい装飾クラスと装飾クラスを追加し、使用時にそれらを組み合わせることができます。元のコードを変更する必要はありません。デコレータ パターンの UML 構造図は次のとおりです:
## ただし、デコレータ パターンにも欠点があります。 2 つ目は、トラブルシューティングが難しいことです。オブジェクトが複数回装飾されている場合、デバッグ中にエラーを見つけるには、段階的なトラブルシューティングが必要になる場合があり、面倒です。
デコレータ パターンの詳細: Java デザイン パターンの構造型: デコレータ パターン
8. 構造プロキシ パターン:
プロキシ パターンの設計動機は、プロキシ オブジェクトを通じて実際のオブジェクトにアクセスすることであり、オブジェクト プロキシ クラスを確立することで、プロキシ オブジェクトが参照を制御します。これにより、実際のオブジェクトに対する操作が可能になります。プロキシ モードでは、プロキシ オブジェクトは主に仲介者の役割を果たし、呼び出し元 (つまり、クライアント) と呼び出し先 (つまり、ターゲット オブジェクト) を調整して接続するために使用されます。これにより、システムとターゲットの結合がある程度軽減されます。オブジェクトが保護されました。ただし、呼び出し元と呼び出し先の間にプロキシ オブジェクトが追加されるため、リクエストの処理が遅くなる可能性があるという欠点があります。 UML 構造図は次のとおりです。
エージェント パターンの詳細: Java 設計パターンの構造タイプ: エージェント パターン
9. 構造タイプ - ブリッジ モード:
ブリッジ モードは、システムの抽象部分と実装部分を分離および切り離し、独立して変更できるようにします。ブリッジモードでは、抽象部と実装部を独立して変更できるという目的を達成するために、継承関係ではなく結合関係を採用しており、抽象部は実装部のインタフェースオブジェクトを持ち、実装部の機能を実現します。特定の実装部分は、このインターフェイス オブジェクトを通じて呼び出すことができます。つまり、ブリッジモードのブリッジは一方向の関係であり、抽象部のみが実装部のオブジェクトを利用でき、その逆は利用できません。
ブリッジ モードは「オープンとクローズの原則」に準拠しており、システムの可用性が向上します。2 つの変更ディメンションでは、1 つのディメンションを変更する必要はありません。実装の詳細を非表示にします。しかし、集約関係は抽象化層で確立されるため、開発者は抽象化に向けたプログラムを作成する必要があり、システムの理解と設計が難しくなります。ブリッジ モードの UML 構造図は次のとおりです。
## Java で JDBC を使用してデータベースに接続する場合と同様に、基本的にはあまり行う必要はありません。コードでは、ブリッジ モードが使用されているためです。JDBC は統一インターフェイスを提供し、各データベースは独自の実装を提供します。その後、ブリッジ クラスがデータベースに接続するためのドライバーを作成します。特定のデータベースを使用する場合、切り替えるだけで済みます。 JDBC の構造図は次のとおりです。
JDBC では、ブリッジ モードの実装役割 (Implementor) は Driver インターフェイスであり、具体的な実装 (Concrete Implementor) は次のとおりです。ロールは MysqlDriver、OracleDriver、MaridbDriver に対応し、拡張抽象化 (Refined Abstraction) ロールは DriverManager に対応し、拡張抽象化ロールの親クラスとしての抽象化 (Abstraction) ロールを持ちません。
ブリッジ モードの詳細: Java デザイン パターンの構造型: ブリッジ モード
10. 構造型-外観モード: 外観モードは、クライアント クライアントは、サブシステム内のインターフェイスのグループにアクセスするための統合インターフェイスを提供します。アピアランス モードの使用には次の利点があります: (1) 使いやすさ: サブシステムが使いやすくなり、クライアントはサブシステムの内部実装を理解する必要がなくなり、サブシステムと通信する必要もなくなりました。多くのサブシステムの内部実装。モジュールと対話するには、外観クラスと対話するだけで済みます。 (2) 疎結合: クライアントをサブシステムから切り離し、サブシステム内のモジュールの拡張と保守を容易にします。サブシステム。 (3) アクセス レベルのより適切な分割: Facade の合理的な使用により、アクセス レベルをより適切に分割できます。一部のメソッドはシステムの外部で使用され、一部のメソッドはシステム内で内部的に使用されます。外部に露出する必要がある機能をファサードに集中させることで、クライアントが使いやすいだけでなく、内部の詳細をうまく隠すことができます。 ただし、出現パターンがサブシステム クラスにあまりにも多くの制限を課すと、多様性と柔軟性が低下するため、出現パターンは、複雑なサブシステムにシンプルなインターフェイスを提供し、システムの使いやすさを向上させるのに適しています。およびシナリオ 外観パターンは、サブシステムをクライアントから分離し、サブシステムの独立性と移植性を向上させるために導入されています。 出現パターンの UML 構造図は以下のとおりです。
出現パターン詳細: Java デザインパターンの構造タイプ: 出現パターン
11. 構造結合モード:
結合モードでは、リーフ オブジェクトとコンテナ オブジェクトを再帰的に結合してツリー構造を形成し、「部分全体」の階層構造を表現し、ユーザーが単一オブジェクトを使用できるようにします。複合オブジェクトは一貫して使用され、複合オブジェクトは区別なくリーフ オブジェクトのように扱うことができるため、ユーザー プログラムを複雑な要素の内部構造から切り離すことができます。
組み合わせパターンで最も重要なことは、リーフ オブジェクトと組み合わせオブジェクトが同じ抽象構築クラスを実装していることです。これは、リーフ オブジェクトとコンテナ オブジェクトの両方を表すことができます。顧客は、この抽象構築クラスのプログラミングのみを行う必要があります。これが、結合パターンがリーフ ノードとオブジェクト ノードを一貫して扱う理由です。組み合わせパターンの UML 構造図は以下のとおりです。
#組み合わせパターンの詳細: Java 設計パターンの構造タイプ: 組み合わせパターン
12, 構造フライウェイト モード: フライウェイト モードは、共有テクノロジーによる小さな状態変化によるきめ細かいオブジェクトの再利用を効果的にサポートします。システム内に同一のオブジェクトが複数ある場合、共有されるコピーは 1 つだけです。毎回オブジェクトをインスタンス化する必要がないため、システム内のオブジェクトの数が大幅に減り、リソースが節約されます。 フライウェイト モデルの中核は、フライウェイト ファクトリ クラスです。フライウェイト ファクトリ クラスは、オブジェクト ストレージ プールを維持します。クライアントがオブジェクトを必要とするとき、まずフライウェイト プールからオブジェクトを取得します。フライウェイト プール, インスタンスは直接返されます。フライウェイト プールに存在しない場合は、新しいフライウェイト オブジェクト インスタンスが作成されてユーザーに返され、新しいオブジェクトはフライウェイト プールに保存されます。これには、シングルトン。 ファクトリ クラスは通常、HashMap、Hashtable、Vector などのオブジェクトを保存するためにコレクション タイプを使用します。Java では、データベース接続プール、スレッド プールなどはすべて、Flyweight パターンを使用するアプリケーションです。 フライウェイト パターンの UML 構造図は次のとおりです:
Java では、String 型はフライウェイト パターンを使用します。オブジェクトの作成後は変更できません。 Java の文字列定数は文字列定数プールに格納され、JVM は定数プール内に文字列定数のコピーが 1 つだけ存在することを保証します。 共有プールに関して言えば、Java の JDBC 接続プールを簡単に考えることができます。接続プールの管理を通じて、データベース接続の共有が実現され、データベース接続を再作成する必要はありません。毎回接続することでデータベースが節約され、再作成のオーバーヘッドによりシステムのパフォーマンスが向上します。
フライウェイト パターンの詳細: Java デザイン パターンの構造タイプ: フライウェイト パターン
これまでに 7 つの構造デザイン パターンを紹介しましたが、次に 11 の動作デザイン パターンを紹介します。 : 戦略パターン、テンプレートメソッドパターン、オブザーバーパターン、反復サブパターン、責任連鎖パターン、コマンドパターン、メモパターン、状態パターン、ビジターパターン、メディエーターパターン、インタープリターパターン。まずは写真を撮って、これら 11 のパターン間の関係を見てみましょう:
13. 行動戦略パターン: クラスは頻繁に変更されるか、変更される可能性があります。変更部分を抽象戦略インターフェースクラスとして抽出し、そのオブジェクトのインスタンスをクラスに組み込むことで、実行時にクラスインスタンスはこのインターフェースを実装したクラスの動作を自由に呼び出すことができます。 たとえば、一連のアルゴリズムを定義し、各アルゴリズムをカプセル化し、それらを交換可能にして、アルゴリズムを使用する顧客とは独立して変更できるようにすることが戦略パターンです。 UML 構造図は次のとおりです:
ストラテジ パターンの利点は、オブジェクトの動作を動的に変更できることですが、欠点は、多くのストラテジ クラスがシステムはさまざまなアルゴリズムの実装のみを提供するため、クライアントはすべての戦略クラスを理解し、どの戦略クラスを使用するかを決定する必要があります。 # 戦略モードは次のシナリオに適しています:
- (1) アプリケーションは特定の機能サービスを実装する必要があり、プログラムには複数の実装メソッドがあるため、いくつかのアルゴリズムから 1 つを動的に選択する必要があります
- (2) A クラスが次のように定義している場合さまざまな動作アルゴリズムがあり、これらの動作はクラスの操作で複数の条件ステートメントの形式で表示されます。関連する条件分岐をそれぞれの Strategy クラスに移動して、これらの条件ステートメントを置き換えることができます。
Strategy パターンの詳細: Behavioral Java 設計パターン: Strategy Pattern
14. Behavioral-Template メソッド:
Template メソッド継承に基づいて実装され、抽象親クラスでテンプレート メソッドが宣言され、アルゴリズムの実行手順 (アルゴリズム スケルトン) がテンプレート メソッドで定義されます。テンプレートメソッドパターンでは、サブクラスの共通部分を親クラスに実装し、特徴的な部分をサブクラスに遅延させることで、特徴的な部分を親クラスで抽象メソッドとして宣言するだけで済みます。サブクラス アルゴリズムの特定のステップは、アルゴリズムの構造を変更せずに再定義でき、さまざまなサブクラスがさまざまな方法でこれらのロジックを実装できます。
テンプレート メソッド パターンの利点は、「開始と終了の原則」に準拠しており、コードの再利用、変更されていない動作の親クラスへの転送、サブクラス内の重複コードの削除も実現できることです。ただし、欠点は、さまざまな実装でサブクラスを定義する必要があるため、クラスの数が増加し、システムが大きくなり、設計がより抽象化されることです。テンプレート メソッド パターンの UML 図は次のとおりです。
テンプレート メソッドの詳細: Java デザイン パターンの動作タイプ: テンプレート メソッド パターン
#15 、行動責任チェーン モデル:
責任チェーンは、リクエスト プロセッサをチェーンに編成し、チェーンに沿ってリクエストを渡すことができます。プロセッサがリクエストを処理できる場合はリクエストが処理され、そうでない場合はリクエストが処理されます。リクエストは処理されますので、上司に任せてください。クライアントは、リクエストを責任チェーンに送信するだけでよく、リクエスト処理の詳細に注意を払う必要はありません。リクエストの送信者とプロセッサは、責任チェーンを通じて切り離されています。これは、責任チェーンの設計動機でもあります。
責任連鎖モデルは、クライアントもプロセッサも相手方に関する明確な情報を持たず、プロセッサは責任連鎖の構造を知らないため、オブジェクト間の相互接続を簡素化できます。すべての候補への参照を保存する必要なく、候補への後続の参照へのポインタを保存します。
さらに、責任連鎖モデルにより、システムの柔軟性が向上します。プロセッサを自由に追加または変更したり、プロセッサの順序を変更したりすることもできます。ただし、いずれにしてもリクエストが処理されない可能性があります。チェーンの最後に配置される可能性があるためです。
したがって、責任連鎖モデルには次の利点があります。
- (1) 結合度を減らし、リクエストの送信者と受信者を分離します。コードに反映されているため、クラス内で多くの見苦しい if...else ステートメントを記述する必要はありません。責任の連鎖が使用されている場合、それはブラック ボックスに直面しているのと同じです。要求を送信するだけで済みます。処理業者の 1 つにブラック ボックスを送り込み、それを配送する責任だけを負います。
- (2) オブジェクトがチェーン構造を必要としないようにオブジェクトを単純化します。
- (3) システムの柔軟性を高め、チェーン内のメンバーを変更したり、順序を移動したりすることでプロセッサを動的に追加または削除できます
- (4) 新しいリクエスト処理クラスの追加 非常に便利です。
ただし、責任連鎖モデルにはいくつかの欠点もあります。
- (1) リクエストが正常に処理されるという保証はありません
- (2) システムパフォーマンスに影響を与える 一定の影響があり、周期的な呼び出しが発生する可能性があります。
- (3) 実行時の特性を観察するのが難しく、コードをデバッグするときに不便で、デバッグに支障をきたします。
責任連鎖パターンの UML 構造図は次のとおりです。
責任連鎖の詳細パターン: 動作 Java 設計パターン :責任連鎖モデル
16. 動作オブザーバー パターン:
オブザーバー パターンはパブリッシュ/サブスクライブ パターンとも呼ばれ、1 つのパターンを定義します。オブジェクト間の多対多の依存関係。ターゲット オブジェクト (オブザーバー) の状態が変化すると、そのすべての依存関係 (オブザーバー) に通知されます。観測対象は複数の観測者に対応でき、これらの観測者は相互に関連していないため、必要に応じて観測者を追加および削除できるため、システムの拡張が容易になり、開閉原則に準拠できます。ターゲット オブジェクトと観測値 観測者は疎結合です。お互いは相手の詳細を知りませんが、対話することはできます。目標オブジェクトは特定の観測者リストのみを知っていますが、特定の観測者は知りません。次のことだけを知っています。それらはすべて共通のインターフェースを持っています。
ただし、オブザーバー パターンの欠点は、オブザーバーが多い場合、すべてのオブザーバーに通知するのに一定の時間がかかることです。オブザーバーとオブザーバーの間に循環依存関係がある場合、システムがそして、観察者モードには、観察者が観察対象がどのように変化したかを知るための対応するメカニズムはなく、観察対象が変化したことだけを知ることができます。オブザーバー パターンの UML 構造図は次のとおりです。
# オブザーバー パターンの詳細: Java デザイン パターンの動作タイプ: オブザーバー パターン #17. ビヘイビア - ビジター モード:
ビジター モードは、オブジェクトのデータ構造とビヘイビアー (データ構造に基づく操作) を分離する方法であり、この分離により、動的なビジターを実現できます。他の変更を加えずに操作を実行すると、各データ構造を変更することなく、これらのデータ構造に作用する新しい操作を簡単に追加できます。これにより、さまざまな種類のデータ構造に複数のアクセス操作メソッドが提供されます。これがパターンの設計動機です。
新しいアクセス操作を簡単にすることに加えて、既存のクラス階層を変更せずにクラス階層の操作を定義し、関連する要素オブジェクトのアクセス動作を分散するのではなく 1 つのアクセスまたはオブジェクトに集中させることもできます。要素クラスを 1 つずつ。
しかし、訪問者パターンの欠点は、新しい要素クラスの追加が困難になることです。新しい要素クラスを追加するたびに、新しい抽象操作を抽象訪問者ロールに追加し、対応する特定の操作をそれぞれ追加することを意味します特定の訪問者クラスへのアクセスは、「開始と終了の原則」の要件に違反します;
したがって、訪問者パターンは、構造内でほとんど変更されないが、多くの場合、このオブジェクト構造 A で定義する必要があるオブジェクトに適しています。アルゴリズム操作を簡単に追加できる新しい操作のシステム、またはオブジェクト構造に対して多くの異なる関連性のない操作を実行する必要があり、これらの操作によってこれらのオブジェクトが汚染されることを避ける必要があり、追加時に操作を変更したくない場合新しい操作、これらのタイプのシナリオ。
訪問者パターンの UML 構造図は次のとおりです。
上記の UML 構造図から、訪問者パターンは主に次のように分かれていることがわかります。 2 つの階層、1 つは抽象訪問者と具象訪問者を提供する訪問者階層であり、主に一部の操作を宣言するために使用され、もう 1 つは要素階層で抽象要素と具体要素を提供し、主に受け入れ操作を宣言するために使用されます。構造体 ObjectStructure は、この 2 つの間のブリッジとして機能し、さまざまな訪問者がアクセスできるさまざまなタイプのオブジェクトを保存します。同じ訪問者でもさまざまな方法でさまざまな要素にアクセスできるため、訪問者モードで新しい訪問者を追加する場合、既存の構造を変更する必要はありません。拡張可能で強力なコードがあります。
ビジター モードでは、ダブル ディスパッチ テクノロジが使用されています。いわゆるダブル ディスパッチ テクノロジとは、メソッドを選択するときに、メッセージ受信者の実行時間の違いだけでなく、メッセージ受信者の実行時間の違いにも基づいて選択する必要があることを意味します。パラメーター。訪問者モードでは、クライアントは特定のステータスをパラメータとして特定の訪問者に渡します。最初のディスパッチはここで完了し、その後、特定の訪問者は「特定のステータス」メソッドのパラメータとして使用され、それ自身のこれもパラメータとして渡されると、ここで 2 回目のディスパッチが完了します。二重ディスパッチとは、結果の実行がリクエストのタイプと受信者のタイプに依存することを意味します。
訪問者パターンの詳細: 動作 Java 設計パターン: 訪問者パターン
18. 動作-メディエーター パターン:
# ワンツー- 1 つの関連付けにより、オブジェクト間の関係が単純化され、理解が容易になります。各オブジェクト間の関係が分離され、各オブジェクトが関連付けられたオブジェクトと直接対話するのではなく、中間オブジェクトを介して関連付けられたオブジェクトと対話します。オブジェクトが相対的に使用できるように通信します。独立して、オブジェクトの再利用性とシステムのスケーラビリティが向上します。 
メディエーター パターンでは、メディエーター クラスが中心となります。システム内のすべてのオブジェクト クラス間の関係をカプセル化します。オブジェクト間の関係を単純化するだけでなく、オブジェクト間の相互作用をさらに制御することもできます。 。メディエーター パターンの UML 構造図は次のとおりです。
ただし、中間オブジェクトはオブジェクト間の関係をカプセル化するため、中間オブジェクトが大きくなり、より複雑になります。また、より多くの責任を負い、維持がより困難になります。各オブジェクトとオブジェクト間の関係を把握する必要があります。それらの間の対話の詳細に何か問題が発生すると、システム全体に問題が発生します。
メディエーター パターンの詳細: 動作 Java デザイン パターン: メディエーター パターン
19. 動作コマンド パターン:
コマンド パターン本質は次のとおりです。リクエストをオブジェクトにカプセル化し、コマンドの発行とコマンドの実行の責任を分離します。コマンドの送信者と受信者は完全に分離されます。送信者はコマンドの送信方法を知るだけでよく、コマンドがどのように実装されているかを気にする必要はありません。実行されるかどうかさえ心配する必要はありません。コマンド パターンの鍵となるのは、抽象コマンド インターフェイスの導入です。抽象コマンド インターフェイス用の送信側プログラムです。抽象コマンド インターフェイスを実装する特定のコマンドのみを受信側に関連付けることができます。
コマンド モードを使用する利点は、システムの結合が軽減され、新しいコマンドをシステムに簡単に追加でき、組み合わせたコマンドの設計も容易であることです。ただし、コマンドごとに特定のコマンド クラスを設計する必要があるため、システムによっては特定のコマンド クラスが多すぎるという欠点があります。
コマンド パターンの UML 構造図は次のとおりです。
コマンド パターンの詳細: Java 設計パターンの動作タイプ: コマンド パターン
20. 動作状態モデル:
状態モデルを使用すると、内部状態が変化したときにオブジェクトの動作を変更できます。オブジェクトは、そのクラスが変更されたかのように見えます。つまり、動作が状態を変えるのではなく、状態はその動作を変えるのがアトミックである、ということです。
オブジェクトの動作がその属性に依存する場合、これらの属性を状態と呼び、オブジェクトは状態オブジェクトと呼ばれます。状態オブジェクトの場合、その動作はその状態によって異なります。たとえば、部屋を予約したい場合、部屋が空いている場合にのみ予約できます。部屋または部屋を予約した場合にのみ、部屋にチェックインできます。無料。このようなオブジェクトの場合、外部イベントが相互作用すると、内部状態が変化し、それに応じて動作も変化します。
状態パターンの UML 構造図は次のとおりです。
上記の UML 構造図から、状態パターンの利点がわかります。
(1) 変換ルールをカプセル化して、巨大な条件文ブロックの代わりに状態遷移ロジックを状態オブジェクトと統合できるようにします
(2) 状態関連のすべてを配置します複数の動作を 1 つのクラスにまとめれば、新しい状態を簡単に追加でき、オブジェクトの状態を変更するだけでオブジェクトの動作を変更できます。
しかし、状態モードの欠点は次のとおりです:
(1) 状態を列挙する前に状態タイプを決定する必要があります
(2) それは増加につながりますシステム クラスとオブジェクトの数。
(3) 「開始と終了の原則」のサポートはフレンドリーではありません。新しい状態クラスを追加するには、状態変換を担当するソース コードを変更する必要があります。そうしないと、新しい状態に切り替えることができなくなります。 ; および特定の状態クラスの変更 この動作には、対応するクラスのソース コードの変更も必要です。
したがって、状態パターンは次のような場合に適しています。コードにはオブジェクトの状態に関連する多数の条件ステートメントが含まれており、オブジェクトの動作はその状態に依存し、それに応じて関連する動作を変更できます。その状態の変化に。
状態パターンの詳細: Java デザイン パターンの動作タイプ: 状態パターン
21. 動作タイプ-メモ パターン:
メモ パターンは、以下を提供します。 a カプセル化を破壊することなく特定の時点でのオブジェクトの内部状態をキャプチャし、それをオブジェクトの外部に保存して、オブジェクトを特定の履歴状態に復元できるようにする状態回復メカニズム。メモ モードでは、保存された詳細がカプセル化されます。メモには、それを作成した作成者以外の他のオブジェクトはアクセスできません。また、保存された詳細を変更してもクライアントには影響を与えないように実装されています。ただし、メモ モードはマルチステートおよびマルチバックアップであるため、より多くのメモリとリソースを消費します。メモパターンのUML構造図は以下のとおりです。
メモモードの中核となるのはメモです。メモに保存されるのは発信者のステータス情報の一部または全部です。このステータス情報は他のオブジェクトからアクセスできないため、使用することができません。オブジェクトこの状態情報の保存にはメモ以外のオブジェクトが使用されますが、内部状態情報が公開されるとカプセル化の原則に違反するため、作成者以外の他のオブジェクトはメモにアクセスできなくなります。したがって、メモ モードのカプセル化を実現するには、メモのアクセスを制御する必要があります。
(1) 発信者: メモ内のすべての情報にアクセスできます。
(2) 担当者、管理者の場合: メモ内のデータにアクセスすることはできませんが、メモを保存したり、メモを他のオブジェクトに渡すことはできます。
(3) その他のオブジェクト：アクセス不可、保存不可 担当者から渡されたメモを受け取り、元のデバイスの状態に戻すのみです。
メモ パターンの詳細: 動作 Java 設計パターン: メモ パターン
22. 動作反復パターン:
反復パターンは、次のアクセス方法を提供します。内部表現を公開することなく、コレクション内の個々の要素を収集します。要素間を移動する責任をコレクション オブジェクトではなくイテレーターに与えることで、コレクション コンテナーの実装が簡素化され、コレクション コンテナーが注目すべきことに集中できるようになります。これにより、単一責任の原則に沿って、次のような作業が不要になります。抽象インターフェイス層には、さまざまなトラバーサル操作が含まれています。イテレータ パターンの UML 構造図は次のとおりです。
イテレータ パターンの詳細: Java デザイン パターンの動作タイプ: イテレータ パターン
23. 行動インタープリタモード:
インタプリタモードは、言語の文法を定義し、その言語の文章を解釈するためのインタープリタを構築することで、頻繁に発生する問題を解決できます。 . 特定の種類の問題の例。
インタプリタ パターンは、単純な言語インタプリタの構築方法を記述します。主にオブジェクト指向言語を使用して開発されたコンパイラで使用されます。単純な言語の文法を定義する方法と、その文法を言語内で使用する方法を記述します。 . は文とその文の解釈方法を表します。
文法規則を使用して言語を定義することに加えて、インタプリタ モードでは、抽象構文ツリーを使用して、言語の構成をより直観的に表現し、より適切に表現することもできます。各抽象構文ツリーは、言語の例に対応します。抽象構文ツリーは、複雑な文を構成する方法を記述しており、抽象構文ツリーを分析することにより、言語内の終端記号クラスと非終端記号クラスを識別できます。インタプリタモードでは、各終端式と非終端式に対応する特定のインスタンスがあるため、システムのスケーラビリティが向上します。
インタプリタ パターンの UML は次のとおりです。
インタプリタ パターンの詳細: Java デザイン パターンの動作タイプ: インタプリタ パターン
推奨学習: 「Java 学習チュートリアル」
## 2. デザイン パターンの 6 つの原則: 
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
