デザインパターンの要約03-行動パターン
1テンプレートメソッド
1.1設計意図
アルゴリズムスケルトンを定義し、特定のアルゴリズムをサブクラスの実装に遅らせます。親クラスは動作を制御し、子クラスはプロセスの詳細を制御します。
1.2ソリューションポイント
コードの共通部分と変更されていない部分を抽出し、サブクラスに変更された部分を拡張させます。フレームワークのような逆の制御を実現し、拡張可能な詳細をユーザーに公開します。
1.3長所と短所
利点
不変でオープンな変数をカプセル化し、メンテナンスを容易にするために共通のコードを抽出します
不利益
- 設計原則:
- サブクラスの拡張:実装ごとに異なるサブクラスがあり、クラスの拡張が発生します。
- 設計レベル:
- パフォーマンスの側面:
- コードは読み取り可能です:
- シナリオの制限:
2戦略モード
2.1設計意図
一連のアルゴリズムを定義し、それらを1つずつカプセル化し、互換性を持たせます。
2.2ソリューションポイント
アルゴリズムの動的選択の問題を解決します。複数の同様のアルゴリズムの場合、if ... elseの使用は複雑であり、維持するのが困難です。
2.3長所と短所
利点
自由に切り替えることができ、次のような複数の判断を回避できます...そうでなければ、優れたスケーラビリティ
不利益
- 設計原則:ユーザーは、戦略カテゴリ、少なくとも名詞のセマンティクスの認識を認識する必要があります。
- サブカテゴリの拡張:戦略アルゴリズムのカテゴリが増加します。
- 設計レベル:
- パフォーマンスの側面:
- コードは読み取り可能です:
- シナリオの制限:
3責任連鎖モデル
3.1設計意図
リクエストの送信者と受信者を結合することは避け、複数のオブジェクトがリクエストを受信できるようにし、これらのオブジェクトをチェーンに接続し、オブジェクトが処理するまでこのチェーンに沿ってリクエストを渡します。
3.2ソリューションポイント
責任の連鎖の処理者は要求の処理に責任があり、クライアントは責任の連鎖に要求を送信するだけで済みます。顧客はリレーションシップリクエスト処理の詳細を必要とせず、各プロセッサはリレーションシップ責任チェーンの処理プロセス全体を必要としないため、問題の複雑さが軽減されます。
3.3長所と短所
利点
リクエストの送信者と受信者を切り離すと、受信者は問題を単純化するためのチェーンを認識せず、処理リンクを動的に追加でき、柔軟性が高くなります。
不利益
- 設計原則:
- サブカテゴリの拡張:処理プロセスが多い場合、絞り込みが多すぎると、処理カテゴリも多すぎます。
- 設計レベル:
- パフォーマンス:チェーンが長すぎるため、パフォーマンスに影響します。
- コードは読み取り可能です:
- シナリオの制限:リクエストは必ずしも処理されるとは限らず、循環依存を引き起こすのは簡単です
4オブザーバーモード
4.1設計意図
オブジェクト間の1対多の依存関係を定義します。オブジェクトの状態が変化すると、それに依存する複数のオブジェクトに通知され、自動的に更新されます。
4.2ソリューションポイント
オブジェクト自体の状態と、状態が変化した後の複数のオブジェクトの処理を切り離すと、複数のオブジェクトが不明になる場合があります。
4.3長所と短所
利点
オブザーバーとオブザーバーは疎結合であり、1つのオブジェクトを複数のオブジェクトと連携させます。
不利益
- 設計原則:
- サブカテゴリの拡張:処理プロセスが多い場合、絞り込みが多すぎると、処理カテゴリも多すぎます。
- 設計レベル:
- パフォーマンス:オブザーバーが多すぎるとパフォーマンスに影響します
- コードは読み取り可能です:
- シナリオの制限:オブザーバーがオブザーバーを呼び出すと、ループコールがトリガーされる可能性があり、オブザーバーはオブザーバーの内部状態変更プロセスを認識しません。
5中間モデル
5.1設計意図
仲介者は、各オブジェクトの呼び出し関係を調整し、各オブジェクトの直接呼び出しを分離する責任があります。
5.2ソリューションポイント
オブジェクトへの直接参照が肥大化したクラス構造と複雑なネットワーク関係につながるという問題を解決します。
5.3長所と短所
利点
各オブジェクトの関係を分離し、最小知識の原則に準拠し、多対多のネットワーク関係を1対多のスター関係に単純化します。
不利益
- 設計原則:
- サブカテゴリの拡張:中間カテゴリが肥大化する可能性があります
- 設計レベル:
- パフォーマンスの側面:
- コードは読み取り可能です:
- シナリオの制限:循環呼び出しを引き起こしやすい
6ステータスモード
6.1設計意図
内部状態が変化したときにオブジェクトの動作を変更できるようにし、オブジェクトがクラスを変更しているように見えるようにします。
6.2ソリューションポイント
解決するオブジェクトの動作はその状態と密接に関連しており、状態が変化すると動作も変化します。
6.3長所と短所
利点
状態遷移ルールをカプセル化し、各状態クラスは単一の責任に沿って特定の状態を処理し、各状態クラスは次の状態アクションへの切り替えを実行できるため、他のような肥大化を回避し、複数のオブジェクトを共有できますステートマシンのセットそしてシステムのオーバーヘッドを削減します。
不利益
- 設計原則:新しい状態リンクが追加されると、元の状態遷移プロセスの変更が含まれますが、これは開始と終了の原則に準拠していません。
- サブクラスの拡張:オブジェクトの状態を取り除くと、必然的にシステムクラスとオブジェクトの数が増えます
- 設計レベル:オブジェクト自体の状態を抽象化することはより複雑であり、抽象化のレベルを非常にテストします
- パフォーマンスの側面:
- コードは読み取り可能です:
- シナリオの制限:
7コマンドモード
7.1設計意図
さまざまな要求がコマンドオブジェクトにカプセル化され、ユーザーは配信のためにさまざまな要求を選択できるため、要求プロセッサは特定の種類のコマンドを気にしません。
7.2解決すべき重要なポイント
動作リクエスター、動作実装者、および動作実行者の間の関係を切り離します。プログラムをより柔軟で制御可能にします。
7.3長所と短所
利点
システムの結合と複雑さを軽減し、新しいコマンドを簡単に拡張できます
不利益
- 設計原則:
- サブカテゴリの拡張:コマンドクラスの拡張を引き起こします
- 設計レベル:
- パフォーマンスの側面:
- コードは読み取り可能です:
- シナリオの制限:
8イテレータモード
8.1設計意図
集約オブジェクトの内部詳細を公開せずに、オブジェクトの内部データをトラバースするメカニズムを提供します。
8.2ソリューションポイント
データトラバーサルをオブジェクト自体から分離し、オブジェクトの内部データをトラバースするさまざまな方法を提供します。
8.3長所と短所
利点
オブジェクトのマルチスタイルトラバーサルをサポートし、反復プロセスはオブジェクトの内部詳細を公開せず、相互に干渉することなく複数の反復をサポートし、イテレータと集約クラスを分離し、それらを互いに独立させます
不利益
- 設計原則:
- サブクラスの拡張:各クラスは反復クラスを提供する必要があります。これにより、クラスの拡張が簡単に発生します。
- 設計レベル:
- パフォーマンスの側面:
- コードは読み取り可能です:
- シナリオの制限:
9ビジターモード
9.1設計意図
主にデータ構造をデータ操作から分離します。
9.2ソリューションポイント
安定したデータ構造と可変演算の結合の問題を解決します。
9.3長所と短所
利点
各訪問者は独立しており、単一の責任に準拠しています
不利益
- 設計原則:アクセスされた特定の各要素を訪問者に知らせる必要があります。これは、最小限の知識と依存関係の逆転に違反します。新しい要素と訪問者のインターフェイスには新しいメソッドが必要です。
- サブカテゴリの拡張:
- 設計レベル:
- パフォーマンス:オブジェクト要素が多い場合、トラバーサルはパフォーマンスに影響します
- コードは読み取り可能です:
- シナリオの制限:各インタビュイーはacceptインターフェースを実装する必要がありますが、これは既存のクラスの拡張には不便です。
10メモモード
10.1設計意図
カプセル化を破壊しないという前提の下で、オブジェクトの内部状態をキャプチャし、この状態をオブジェクトの外部に保存します。
10.2ソリューションポイント
カプセル化を破壊しないことを前提として、オブジェクトの内部状態をキャプチャし、この状態をオブジェクトの外部に保存して、将来オブジェクトを元の状態に復元できるようにします。
10.3長所と短所
利点
状態のロールバックに便利で、ユーザーは状態の保存の詳細を気にする必要がありません
不利益
- 設計原則:
- サブカテゴリの拡張:
- 設計レベル:バックアップが必要なオブジェクトの状態が多数ある場合、内部状態を抽象化することは技術的な作業です。
- パフォーマンス:バックアップは必然的にリソースを浪費します。
- コードは読み取り可能です:
- シナリオの制限:
11通訳モード
11.1設計意図
言語と文法の表現が与えられ、インタプリタを定義すると、インタプリタは識別子を使用してその言語の文を解釈します。
11.2解決すべき点
一部の固定文法では、文を説明する通訳を作成します。
10.3長所と短所
利点
式を増やすと、新しいインタープリターサブクラスを拡張できます。これは、優れたスケーラビリティと高い柔軟性を備えています。
不利益
- 設計原則:
- サブクラス拡張:インタープリタークラスの拡張を形成します
- 設計レベル:抽象的な設計レベルに対する高い要件
- パフォーマンスの側面:
- コードは読み取り可能です:
- シナリオの制限:利用可能なシナリオが少なくなります