七つの設計原理
A.オープンクローズ原理
閉鎖原則（オープンクローズ原理、OCP）は、拡張のためのオープンが、修正のために閉じなければならないソフトウェアエンティティ（例えば、クラス、モジュール、および機能）を指します。開閉いわゆる、また、2の動作を拡張し、変更するための原則です。それは達成展開の詳細を抽象化して、建物のフレームは、ソフトウェアシステムの再利用性と保守性を向上させることができると強調しました。オープニングとオブジェクト指向設計の原則を閉じるには、我々は安定した、柔軟なシステムを構築する方法をガイドすることを最も基本的な設計原理です。たとえば、バージョンアップのために、私たちは、ソースコードを変更しないようにしよう、しかし、あなたは新しい機能を追加することができます。
II。依存関係逆転の原則
依存性逆転原理（依存反転原理、DIP）が設計コード構造を指す場合、層モジュールは、抽象化に依存する必要がありどちらの基本モジュール、に依存してはなりません。要約は、詳細は抽象的に依存しなければならない、細部に頼るべきではありません。クラスとクラスの間の結合を低減し、システムの安定性を向上させることができる反転依存することにより、コードの可読性と保守性を向上させ、プログラムを修正することによって引き起こされるリスクを低減します。
III。シングル責任原則
シングル責任原則（シンプル責任Pinciple、SRP）は、複数のクラス変化よりも起こさない理由があることを意味します。ロジックの責任、義務で障害が発生した別の関数につながる可能性のあるコードを修正し、我々は需要が変更されると、クラスは、責任の二つの領域を担当していたとします。その結果、このクラスは、クラスの変更につながる二つの理由があります。どのようにこの問題を解決するには？実装するには、2つのクラスを持つ2つの関数、デカップリング。ポストメンテナンス要件は、互いに独立して変化します。このデザインは変更に起因するリスクを低減、システムの保守性を向上させる、クラスが読みやすく、クラスの複雑さを軽減することができます。全体的に、それは、クラス、インターフェイスまたはメソッドが義務のための唯一の責任です。
IV。インタフェースの棲み分け原理
界面分離原理（インターフェース偏析原理、ISP）がそれに依存してはならないクライアントは、インタフェースはなく、単一の一般的なを使用することなく、専用のインターフェース、複数のインタフェースの使用を指します。
インターフェイスのデザインで私たちを導く原則は、次の点に注意してください。
他のクラスに依存して（1）クラスは、インターフェイスの最小値に基づくべきです。
（2）は、単一のインターフェイスを確立、肥大化したインターフェースを作成しないでください。
インターフェースを最小限に抑えることができる改良プロセスインタフェース（3）（良くない、適切でなければなりません）。
私たちはしばしば高い凝集と低カップリング設計を言うとラインのインタフェースの分離の原則は、クラスが良い読みやすさ、拡張性と保守性を持って行うことができます。私たちは、必要性は、いくつかの事前の判断を行うことが可能な場合、将来の変化が起こるなど、ビジネスモデルを検討するために、時間を費やし、時間のインターフェースの設計について考える必要があります。だから、抽象的なため、ビジネスモデルを理解することは非常に重要です。
V.ドミトリー原則
ディミトリス原理（法ofDemeter LOD）は、クラスとクラスの間の結合の程度を最小限に抑えるために、また、少なくとも既知の原則（最小知識の原則、LKP）として知られている他のオブジェクトの最小の理解に維持されるべき物体を指します。ディミトリス主な原則が強調：友達との通信の合計は、見知らぬ人に話をしません。メソッド本体は、友人のクラスに属していない内部のメンバ変数、メソッド、入力および出力パラメータに表示されるようになりましクラスのうち、クラスの友人のクラスのメンバを呼び出すことができます。
VI。リヒター置換原則
リヒター置換原理（リスコフの置換原則、LSP）オブジェクトO1 T1の種類ごとに、T2は、オブジェクトの種類である場合には、O2 P T1定義されたすべてのプログラムが全てで置換されているように、O1、O2オブジェクトことを意味、プログラムPの挙動は、その後、型がタイプT2 T1のサブタイプである、変化していません。
この定義はかなり抽象的だが、我々はそれを再度理解しています。ソフトウェアエンティティとして理解することができ、親クラスに適用された場合、それはそのサブクラスの明確でなければならないオブジェクトを使用して、親クラスへのすべての参照は、サブクラスのオブジェクトは、親オブジェクトに置き換えることができ、そのサブクラス、プログラムロジックを適用する必要があります変わらず。
この理解によると、意味の拡張：サブクラスは親クラスの機能を拡張することができますが、親クラスの本来の機能を変更することはできません。
（1）メソッドのサブクラスは、抽象親クラスを想像することができますが、非抽象親クラスをカバーすることができません。
（2）サブクラスは、独自の方法を増大させることができます。
前提条件（3）親クラスのサブクラスオーバーロード、方法よりリラックスした親クラスのメソッドより入力パラメータ（内/パラメータを入力するための、すなわち、方法）。
（4）場合、親クラスの実装サブクラス（書き換え/又は抽象メソッドオーバーロードを実装する）、プロセスの事後条件（すなわち、プロセス出力/戻り値）親クラスよりも、または緊密スーパークラス以下のような
リヒター置換原理を使用する利点：
（1）の制約は、それが開閉の原理を反映して、フラッディング継承しました
（2）は、同じ時間変化で、プログラムの保守性とスケーラビリティを向上させながら、非常に良好な相溶性を行うことができ、プログラムの堅牢性を強化し、要件変更の導入のリスクを軽減します。
多重化の原則のVII。合成
原則（コンポジット/骨再利用原理、CARP）を多重合成ではなく、ソフトウェアの再利用の継承目的の可能な物体組成物（HAS-）/重合（contanis - ）を指します。あなたは、クラスとクラス間の結合を低減するために、システムをより柔軟にすることができ、他のクラスのクラスの影響で比較的小さな変化が生じました。