デザインパターンの6つの原則
- 単一責任の原則
- リヒターの置換原則
- 依存関係逆転の原則
- インターフェイスの棲み分け原理
- ドミトリー原理
- オープンクローズ原理
デザインパターンの分類
スキーマを作成します。
オブジェクトがシステム内に作成する方法をカプセル化する抽象クラスで定義されたインタフェース、その他の情報の組み合わせを使用して、抽象オブジェクトインスタンス化：スキーマを作成します。これは、次のデザインパターンを含み
Abstract Factoryパターン
利点
- 分離された特定のクラス
- 製品ラインを変換する方が簡単
- 製品間の一貫性を向上
短所
- 新製品階層をサポートすることは困難
- オリジナルの抽象ファクトリインタフェースを拡張する新しい製品階層をサポートしています
該当シーン
- システムは、製品の作成、組成及び表現とは無関係です
- システムは、複数の製品のシリーズで構成されています
- 私は、オブジェクトの共同利用を促進するために設計された関連製品のシリーズを強調したいとき
- 場合は、製品のクラスライブラリ、およびそのインターフェイスを表示したいのではなくときに実現
アプリケーション例
あなたは、多くのソフトウェアシステムでAbstract Factoryパターンの設計時間を使用することができるなど変更されたテキストボックス、背景色、一緒にインタフェースのテーマ、ボタン、インタフェース要件を、交換する必要があります
ビルダーモード
利点
- 製品の内部表現は、独立して変化することができます
- 製品組成物の内部の詳細を知る必要がないクライアントを引き起こす可能性があり、コードの相分離を表す建築基準
短所
- ビルダーモードを作成した製品は、一般的に共通でより多くを持っている素晴らしい製品との差異場合、そのコンポーネントは似ています。建設モードは適していません
- 製品の複雑で内部的な変更は、この変更を実装するための具体的なビルダークラスを定義する必要性の多くを引き起こす可能性がある場合は、システムが非常に大きくなる原因
該当シーン
複雑なオブジェクトにその収集し、道の独立したアルゴリズムを作成し、オブジェクトの構成のこれらの部分
の建設プロセスは、オブジェクトの異なる表現が構築されている許可する必要があります
アプリケーション例
スカイマップ、グランド背景の一部など人体の一部、衣類、機器、などの文字を含む多くのゲームソフトでは、あなたは、Builderパターンのデザインを使用することができ、異なる特定のビルダーでのマップの種類を作成したり、フィギュア
Factory Methodパターン
オブジェクトを作成するための定義（製品の）（製品）インタフェース、そのクラスのオブジェクトをインスタンス化するサブクラス
利点
- アプリケーション・コードを結合する要件がない、唯一のインタフェースを処理するコードは、インタフェースの任意のタイプを使用して実施することができます
- サブクラスは、オブジェクトの拡張版を提供できるように
- デメテルの法則、依存関係逆転の原則、リヒターの置換原則に沿って、
短所
- クリエーターとアプリケーションモデルは、作成者サブクラスが存在する必要がない場合も、キャリアファクトリメソッドとして対応するサブクラスを必要とする、またはクラス階層を追加する必要があります
該当シーン
- クラスは、彼は製品を作成したかの詳細を知っていないと、そのときのサブクラスであります
- あなたは、サブクラスするプロセスを遅らせるために、希望のオブジェクトを作成すると
クラスのサブクラスは、彼が指定したオブジェクトを作成したいです
アプリケーション例
MFCとWindowsのCOMコンポーネント
プロトタイプモード
オブジェクトの型を作成する場所を指定し、彼によって新しいオブジェクトを作成するために、プロトタイプとして、既存のオブジェクトへのプロトタイプをコピーして新しいオブジェクトを作成します
利点
- 許可された場合は、製品を追加または削除することができます
- プロトタイプモードは、作成した簡単な構造を提供します
- アプリケーションは、新しいソフトウェア機能をロードする機能を持っています
このような製品は、任意の実装階層によって決定される必要がありません
短所
各タイプは、クローニング法を装備しなければなりません
該当シーン
- 実行時に、クラスのインスタンスは、例えば、動的ロード、類似製品共産クラス階層とクラス階層の構築を避けるために指定する必要があります
このクラスは、いくつかの異なる状態の組み合わせの一例に過ぎない場合には
シングルトン
クラスの唯一のインスタンス
利点
- の単一インスタンスへのアクセスを制御することにより、
- 名前空間の減少
- 改善された動作を可能と表します。
- 可変数のを可能にする例
操作の種類よりも柔軟
短所
拡張シングルトンクラスには、ある程度の単一責任の原則に反することは非常に困難と重い義務です
該当シーン
クラスの唯一のインスタンス
アプリケーション例
徐々に発電機
構造モデル
主に統一された外部またはしようとした新機能を提供するためのインタフェースを実装するために継承メカニズムの組み合わせを使用し、より大きな構造を得るためには、既存のクラスとオブジェクトを結合する方法について
アダプタモード
クライアントが期待する別のインターフェイスへのクラスのインタフェースを変換し、アダプタパターンは、元のインターフェイスは互換性がないため、これらのクラスが一緒に働くことができるでは動作しないことができます
利点
- 二つ以上の互換性のないオブジェクトが相互作用して通信できます
- 該当の繰り返しの既存の機能を向上させます
- クラスの透明性を高めます
- 柔軟性
短所
あまりにも多くの全体を把握するために、システムは、適切なアダプタは非常に厄介で困難になります
該当シーン
- 既存のクラスを使用するには、クラス・インターフェースとインターフェースが一致する必要はありません
- 再利用可能なクラスを作成するには、このクラスは、無関係なまたは未知のクラスとの間で互換インタフェースである何のクラスを助けることはできません
- 環境へのインタフェースにターゲットを再使用するには、既知のとは異なり
- インターフェースは、複数のソース間で変換する必要がある場合
アプリケーション例
達成された重い.NETクラスライブラリでは、それは重要なアダプタ--dataアダプタです
ブリッジモード
二つの別個のしかし関連継承階層に補助成分
利点
- インタフェースは、相分離を用いて実施することができます
- スケーラビリティの向上
クライアントの非表示の実装の詳細
短所
- 理解の難しさを増やし、システムを設計します
適切に二つの別々の重量変化の大きさを特定し、そのためその使用はいくつかの制限を有しているシステム
該当シーン
- 私たちは、抽象化とその実装間の恒久的な結合が存在しないようにしたいです
- その実装は、拡張抽象サブクラスを使用することができます
- 変更がクライアントに影響を与えるべきではない抽象達成
複合モード
階層 - ツリー構造へのオブジェクトは、「全体の一部」を表現するために
利点
- オブジェクト階層のすべてまたは一部を表す複雑なオブジェクトの明確に定義された階層
- このようなことが容易に新しいメンバーを追加します
- インターフェイスの柔軟性と管理構造を改善
短所
デザインは、より抽象的になります。ビジネスルールは、モードの組み合わせで実現される複雑なオブジェクトがある場合は非常に困難ですが、オブジェクトに関連付けられたすべてのメソッドは、サブクラスを残していません
該当シーン
- 私は、オブジェクトの一部を表現したいと思います - 階層全体を
- 別のユーザーが単一のオブジェクトとオブジェクトの組み合わせを無視すると、ユーザはすべての重い物の統一された構造の組み合わせを使用します。
構造は、複雑さの任意のレベルを有するが、動的できます
アプリケーション例
管理セクション、ツリーメニュー、ファイル、フォルダなど、シーン全体
装飾的なパターン
いくつかの追加の責任に動的オブジェクトを追加し、機能性の向上は、装飾は、サブクラスよりも柔軟です
利点
- 静的な継承よりも柔軟に対応
- コードを簡素化
- 改善された機能拡張オブジェクトは、ユーザーが新しいクラスを書くことで変更を行うことができます
- 装飾や装飾は、独立して開発することができ、相互に結合されていません
短所
多層装飾コンプレックス
該当シーン
- 単一のオブジェクトでは、ダイナミックかつ透明な責任を追加したいが、これは他のオブジェクトには影響しません
- 責任を追加した後の目標重量で修正される可能性がしたいです
- 彼らは、静的なサブクラスの拡張を介して達成することができない場合には
Facadeパターン
サブシステムは、使いやすいインターフェイス重みのセットに均一なインターフェース、外部システムとサブシステムとの間の相互作用の複雑な分離の高レベルインタフェースモードの出現、サブシステムのような複雑なシステムを提供します
利点
- システムによって提供されるオプションを低下させることなく、複雑なシステムにシンプルなインターフェイスを提供
- クライアント・サブシステムのシールドアセンブリ
- サブシステムとそのクライアント間の弱い結合を改善
- クライアント要求の処理サブシステムは、転送した後、このような要求をすることができ
短所
- 顧客のアクセスサブシステムがあまりにも多くの制限を行う場合には、サブクラスの顧客の制限のない良い使用は、それが多様性と柔軟性を低減します
- 外観の開閉の原則に反して、あなたがソースコードやクライアントの外観を変更する必要があり、新たなサブクラスを追加し、抽象クラスを導入することなく
該当シーン
- 複雑なサブシステムへの単純なインタフェースを提供しながら、
- そこクライアントとの間に有意な依存関係があり、抽象クラスを実装します
- 階層のサブシステムを構築する場合、サブシステムの定義は、各エントリポイントのファサードパターンを適用するサブシステム間で相互に依存している場合、あなたは彼らがそれらの依存関係を簡素化し、唯一のファサードを介して通信することができます関係
フライ級
低レベルの共有オブジェクト、詳細にオブジェクトの数によって低減システム
利点
- 処理するオブジェクトの数を減らします
- オブジェクトを持続させることができるならば、それはメモリとストレージデバイスを減らすことができます
短所
- ようにすることで、アプリケーションがより複雑になります
- オブジェクトを作成するためにフライ級フライ級外部のオブジェクトの状態の必要性、および外部の読み出し動作時間が長くなるような状態を共有することができます
該当シーン
- アプリケーションは、多数のオブジェクトを使用しています
- 高いストレージ・オーバーヘッドをもたらす多数のオブジェクト、に
- アプリケーションは、オブジェクトのアイデンティティに依存しません
プロキシモード
元のオブジェクトへのアクセスを制御するために、エージェントまたはプレースホルダオブジェクトが提供され
利点
- リモートプロキシは、オブジェクトが異なるアドレス空間にあるという事実を隠すことができます
アラートは、操作を最適化するために行うことができます
短所
- 要求の処理速度が遅くなります
プロキシモードを実装するため、システム実装の複雑さを増す、追加の作業が必要です
該当シーン
- 異なる内のローカルアドレス空間のオブジェクトの代表を提供することが望まれる場合
あなたはオーバーヘッドが非常に大きなオブジェクトを作成する必要がある場合
アプリケーション例
ターゲットの近くに悪意のあるユーザーを防ぐために---プロキシファイアウォール保護
行動モデル
基本的な枠組みや基準などの行動の抽象的な理論のうち多くのアクションから一般、クラスモデルは、主にオブジェクト間の責任やサービスを割り当てるために使用され、彼はモデルオブジェクトやクラスを記述するだけでなく、彼らはまた、説明します間の通信モード
Chain of Responsibilityパターン
システム内のリンクを確立し、受信されたメッセージは、最初に彼のレベルに処理することができる、又はその標的を見つけるために処理することができます
利点
- デカップリング
- オブジェクトに指定された責任の柔軟性を高めます
該当シーン
- 複数のオブジェクトを処理することができる要求し、プロセッサに未知であります
- 動的に指定されたオブジェクトが要求を処理できる設定
コマンドモード
オブジェクト要求をカプセル化し、saveコマンドのメソッドに渡され、他のオブジェクトには、コマンドを返します。
利点
- 既存のクラスを変更せずに新しいコマンドを追加します。
- そして、操作対象オブジェクトは、動作の相分離を完了する方法を知っています
該当シーン
- 実行されるアクションを通じてパラメトリックオブジェクトにしたいです
- 異なる時刻に指定され、実行要求を並べ替えます
Interpreterパターン
その構文定義言語表現を説明
利点
- 簡単に変更と拡張構文
- 構文は、実現するのは簡単です
該当シーン
- 言語構文は比較的簡単です
- 効率が主な問題ではありません
イテレータパターン
内部に、露出されたオブジェクトの表現を変更することなく、ポリマー物体の各要素に順次アクセスする方法が提供され
利点
- 別のサポートのコレクションを
- コレクションインタフェースを簡素化
該当シーン
- 表された内部オブジェクトのセットを開くことなく、コレクションオブジェクトのコンテンツにアクセス
- 複数のサインオブジェクトトラバーサルをサポートしています
- これは、異なる構造のコレクションを横断する統一されたインタフェースを提供します
Mementoパターン
外の世界にその内容を開示せずに、元の状態に戻るには、オブジェクトの状態「スナップショット」を維持します
利点
- そのままパッケージを維持するために、
- これは、動作の初期状態に必要なリターンを簡素化
該当シーン
- あなたは、オブジェクトのスナップショットを保存する必要があります
- 適切な実装の詳細を取得する直接インターフェイスは、オブジェクトの破壊をカプセル化するために、ここでの目的状態に開示されていることができます
Observerパターン
これは、受信コンポーネントに関連するブロードキャストメッセージに対する柔軟なアプローチを提供します
利点
- 本体と観察者との間の抽象結合
- 通信と放送モードのサポート
該当シーン
- 変更は、他のオブジェクトへのオブジェクトへの変更を伴うが、変更する必要がどのように多くのオブジェクトがわかりません
- オブジェクトはオブジェクト識別子を設定せずに、他のオブジェクトに通知することができなければなりません
ステート・モード
その動作を変更する際の内部状態の変化とそのクラスを変更するオブジェクトを許可します
利点
- 位置決め状態の挙動を指定し、そして行動を分割する状態に応じて
該当シーン
- その状態に応じて行動をオブジェクト、およびオブジェクトは、実行時の状態に基づいてその動作を変更する必要があります
- マルチ状態の組成物のどの部分に応じて条件文の多数を操作
戦略モード
これは、可能な行動の集合を表すために使用されるクラスのセットを定義します
利点
- 別の方法種子
- 条件文を減らし、クラス自体の動作を定義します
- よりスケーラブルなモデル
該当シーン
- 多くの関連クラスは、製図の点だけが異なります
- このアルゴリズムは、さまざまなバリエーションが必要です
- 不明なアルゴリズムでは、クライアントデータを使用しています
Template Methodパターン
それは方法の負荷の高い部分なしでサブクラスがメソッドをオーバーライドできるようにする方法を提供し、
利点
- コードを使用します
該当シーン
- サブクラスは、アルゴリズムの変数の動作を実装するためのアルゴリズムの一定の一部を実現したいです
- サブクラス間で共通の行動は、コードの重複を避けるために、一般的なクラスを見つけるために、壊れする必要があります
Visitorパターン
これは、オブジェクト構造要素上で実行利用可能なメンテナンス作業を表現する便利な方法を提供します。モードは、新しいオペレーティング要素の動作クラスを変更することなく、前提の変化を定義できます
利点
- 新しい操作を追加するのは簡単
濃度関連業務と無関係な操作を排除
該当シーン
- クラス定義のオブジェクト構造はほとんど変化しないが、この構造に新しい操作を定義したいです
オブジェクト構造は、異なるインターフェースを有するオブジェクト・クラスを複数備え、操作のこれらのクラスの特定のオブジェクトに依存したいです
仲介モデル
被写体を導入することにより、オブジェクト間通信システムを簡素化することを目的とするメッセージの配信を管理することができます
利点
- オブジェクト間の抽出に及ぼす影響
- オブジェクト間の単純化されたプロトコル
- 集中管理
該当シーン
- オブジェクトのセットを定義しますが、複雑な双方向通信を必要とします
- 複数のオブジェクトの行為の間に分散カスタムサブクラスを使用せずにしたいです
ブログ記事複数のプラットフォームからこの記事OpenWriteリリース！