デザインパターンは3つのカテゴリに分類されています。
- ：、5つのカテゴリーの合計スキーマを作成しますFactory Methodパターン、Abstract Factoryパターン、シングルトン、Builderパターン、プロトタイプモデルを。
- 構造モデル、7種類の合計：アダプタモード、装飾的なモード、プロキシモード、外観モード、ブリッジモード、組み合わせモード、フライ級。
- 行動パターン、11種類の合計：Strategyパターン、テンプレートメソッドパターン、オブザーバーモード、イテレータパターン、責任のチェーン・モード、コマンドモードモードを説明するために、メモモード状態モード、ビジターパターン、仲介モデル。
デザインパターンの6つの原則：
- 一般的な原則 - 開閉の原則
- 拡張のためのオープン、修正のため閉鎖。プログラムを展開する必要がある場合、元のコードを変更しますが、ホットスワップ可能なの効果を達成するために、既存のコードを拡張しません。プログラムスケーラビリティを作るためには、メンテナンスとアップグレードの容易さ：だから、一つの文章にまとめました。
- 1.シングル責任の原則
- それ以外の場合は、クラスを分割する必要があり、各クラスは、単一の責任を実装する必要があることを意味し、変更の複数の原因を入力しないでください。
- 2、リヒターの置換原則（リスコフの置換原則）
- 任意の基底クラスが表示されることができ、サブクラスが出現することができます置きます。代替原則リヒターは、派生クラスが上のベースクラスに基づいて新しいを追加することができ、派生クラスは、基本クラスを置き換えることができた場合にのみ、機能のソフトウェアユニットが影響されない、基底クラスが実際に再利用できる多重礎石を継承しました行動。
- リヒターの置換原則がある - 「オン - オフ」の原則を追加します。「オン・オフ」の原則を達成抽象化の重要なステップです。リヒター置換原理は抽象を達成するための具体的な措置のための仕様であるように、基本クラスとの継承関係は、抽象的、具体的な実現のサブクラスです。リヒターは、原則的に置き換えサブカテゴリと親クラスのメソッドのオーバーロードを上書きしないようにしてください。親クラスが明確に定義された構造を表しているので、外の世界と対話するために、このインタフェース仕様によって、サブクラスはそれを破壊してはいけません。
- 3、依存関係反転原理（依存反転原理）：抽象的、詳細に頼るべきではありませんが、詳細は抽象的に依存しなければなりません。 - 人気のトークは、プログラミングを実装するのではなく、プログラミングするためのインタフェースです。
- 4、インターフェイス分離原則（インタフェース分掌の原則）：クライアントはそれに頼るべきではありません、インタフェースはありません。このクラスの別のクラスへの依存は、最小のインターフェイスに基づいている必要があります。
- 可能な限り小さくインターフェースが、制限があります。プログラミング・インタフェースの柔軟性を改善するには、改善することができる紛れもない事実ですが、それが小さすぎる場合、それは設計を複雑に、インターフェースの過剰な数の原因となります。だから、中等度にしてください。
- 依存インターフェイスにサービスをカスタマイズし、唯一のメソッドを呼び出すためにクラスを公開することは、それを必要とし、それは方法が隠されている必要はありません。最低限の依存関係を確立するために、モジュール用にカスタマイズされたサービスを提供することに焦点を当てます。
- 結束を改善し、外部の相互作用を減らします。以上の方法とのインタフェースは、ほとんどのものを達成します。
- 5、デメテルの法則（少なくとも知られている原則）（デメテル原理）
- その依存クラスのクラスは、よく知っています。どんなに複雑な依存クラス、ロジックは、メソッド内にカプセル化されるべきではない、それは、publicメソッドを介して外部に供給されています。変更は、クラスへの影響を最小限に抑えながら、依存クラスであるときようにします。
- 少なくとも、既知の原理の別の表現は次のようになります。友人とのみ直接通信。限り、クラス間の友情と呼ばれる結合関係があるよう。依存性、会合、凝集、等の組合せに結合します。私たちは、直接クラスの友人にメンバ変数として表示され、メソッドの引数、メソッドの戻り値を呼び出します。ローカル変数は、一時的な変数は直接の友人ではありません。私たちは、クラスは、クラス内のローカル変数として表示されません見知らぬ人に尋ねます。
- 図6に示すように、多重化原理（複合リユース原理）の合成：合成ポリマー/代わりの継承を使用するすべての可能な方法の最初。
