七つの原則：1.開閉の原則
開閉原則（OCP）：このようなクラス、モジュールや関数などのソフトウェアエンティティは、拡張のために開いている必要がありますが、変更のため閉鎖。プログラムの目的は、スケーラビリティ、容易なメンテナンスやアップグレードを確保することです。
開閉原理は実際には、他の原則は道具や楽器の開閉の原則の実現として見ることができ、オブジェクト指向設計の礎石として知られています。手段：ソフトウェアは、拡張のために開いている必要があり、修正が閉じられている、それはこれらの拡張をしながら、それは元のプログラムに変更を必要としない、ソフトウェア機能の開発が延長されなければならない、人気があります。
利点は以下のとおりです。ソフトウェアの利用可能性は非常に柔軟、かつ強力な拡張です。ときに新しい機能は、新しい需要を満たすために新しいモジュールを追加することができます。また、元のモジュールが変更されないよう、その安定性を心配しないでください。
2.単一責任の原則
シングルResponsibilitiy原則（SRP）：クラスのために、それはそれの原因でなければなりませんが、単に変更です。複数動機は、クラスを変更する場合は、そのクラスは、あなたがそれぞれの役割を完了するために、いくつかのクラスを作成して行く、余分な業務を分離する必要があり、複数の役割を持つことになります。
例：人物いくつかの役割が、これらの事はあまり関係、でも葛藤、そして彼は責任が別の人に割り当てる必要があるこれらの問題に対する良い解決策ではないことは、それを行います。
単一責任の原則は、カップリングではなく、一つに高凝集や低を達成するための最良の方法です。
3.リヒター置換原則
リスコフの置換原則：サブクラスは親クラスの機能を拡張することができますが、元の関数の親クラスを変更することはできません。
閉鎖原則、その「抽象的」とオープニングの最初の原則として「多型」を デザインのカプセル化「抽象」を維持することは、言語が継承セマンティクスで実装「多型」、機能を提供しています。それでは、どのように継承関係の品質を測定するには？
答えは：継承が明示的にスーパークラス（親クラス）保有物件はまだサブクラスに設定されていることを確認する必要があります。
オブジェクト指向の考え方では、オブジェクトは状態の集合と一連のアクションを組み合わせたものです。ステータスは、動作は、オブジェクトの外部特性物体の固有の特性です。LSPの形成での表現は、同じ継承階層は、共通の行動特性を持つべきです。
4.依存関係反転
依存性逆転の原則（DIP）：クラスとクラス間のルールを呼び出します。ここで、結合に依存するコードです。レイヤモジュールは、抽象依存すべきどちらの基礎となるモジュールに頼るべきではありません。抽象的な内容には依存しません。詳細は抽象化に依存すべきです。インタフェースプログラミング。
主なアイデアは、これを次のとおりです。クラスやパラメータの特定のタイプのメンバーがする場合は、このクラスは、特定の種類に依存します。継承構造場合、クラスの上部部材以下パラメータタイプは、次に継承構造は、基礎レベルに依存している、または抽象プログラミングインターフェースに努めなければなりません。
例えば：Driverクラスの存在、カーオブジェクト部材、及びドライバ（）メソッド、カーオブジェクトは2つの方法が（起動している）、停止（）。明らかに、この方法Carクラスと呼ばれているドライバーの依存カー、ドライバーのクラス。しかし、バスドライバクラスクラスのサポートの増加は、（バスドライバを開く必要がある）、あなたがドライバのコードを変更しなければならないとき、オープンクローズドの原則を損ないます。根本的な理由は一緒にクラスのカードライバークラスの上部と下部との結合ということです。一つの解決策は次のとおりです。バスカークラスと抽象クラス、抽象クラスAutomobleの導入。車やバスが自動車の一般化です。
抽象化に依存するようになると同時に、下層のハイレベル、上下に頼るような変換の検索後。これは、自然の依存関係逆転の原則です。
界面分離
界面分離原理（InterfaceSegregation原理）：役割と適切なインターフェイスを分割するため、二つの意味があります：1 、それがユーザインタフェースに頼るべきではないない ; 2、クラス間の依存関係は、最小のインターフェイスに基づくべきです。
これら二つの定義は、一つの文章にまとめ代わりに肥大化したインターフェースの、単一のインターフェイスの設立。人気はこれです：少ないインターフェースメソッドを確保しながら、可能な限り、インターフェイスを改良してみてください。インタフェースが含まれている場合の挙動の多くは、正常な関係につながる行うには、クライアントに依存しないデカップリングできます別のインタフェースです。
単一責任の原則に戻るには、上記、必要な別のインタフェースインタフェースはやや同じ感じ、行動を洗練しました。しかし、実際には、単一のインタフェースを持つデューティクラスの単一責任の原則は、責任に焦点を当て、できるだけ少ないインタフェースの要件はありません。
界面分離原理は、それ専用の複数のインタフェースを利用するために必要とされます。複数のモジュールへのインターフェイスに提供される特別なインタフェース。提供するいくつかのモジュールではなく、肥大化したインターフェースを作成する、すべてのモジュールにアクセスすることができ、いくつかのインターフェースを有していなければなりません。
しかし、インターフェースの設計が制限されます。より柔軟なシステムインタフェース設計より小さい粒径が、それは本当ですが、それはまた、構造、難しいメンテナンスインタフェースが複雑すぎます。実際にはそう、開発に依存する経験や常識を把握する方法。
6.ドミトリー原則
デメテル（原則の最小知識）の法則：オブジェクトが他のオブジェクトの最小限の理解している必要があります。人気は、ということである自分自身の必要性のクラスは、カップルを知っている、あるいは少なくとも、私が呼び出すことができ、私はあなたが非常に多くの一般的な方法を知っている、私はあなたのものだと、気にしないどのように複雑なクラス内のクラスを呼び出すこと。
ディミトリス原理は、クラス間の直接接触を確立することを望んでいません。あなたが本当に接触を持っている必要がある場合は、その友人のクラスによって伝えるために。例えば：あなたが家を購入する必要があり、現在発売A、B、Cのための3つの適切な特性がありますが、あなたはフラットを購入する不動産に直接行く必要はありませんが、営業所に状況を理解します。これは、あなた（買い手）と2つの不動産クラス間の結合を低減します。
しかしデメテルの原則の適用は、結果での結果に思われる：転送クラス間の関係、意志お互いを呼び出すために存在する（例えば、クラス以上の営業所など）の中間クラスがたくさんあるシステムこれは、システムの程度の複雑さを増大させます。
ディミトリスコア原則考え方は次のとおりです。クラス、弱いカップリングの間のデカップリング。
7.合成/多重化原理
代わりに相続の、オブジェクト構成/重合を利用するためには、クラス間減らすために、ソフトウェアの再利用の目的を達成するために
小さいクラスの変化に影響される結合度が他のクラスに持っています
