1.シングル責任
人気の簡単な言葉：クラスは義務のための唯一の責任です。
元の利点の一つの責任をフォローしています：
- クラスの複雑さを軽減することができ、クラスは、そのロジックは単純責任の数を担当してより良い確かに、義務のための唯一の責任です。
- メンテナンス性を向上させ、クラスの可読性を向上させます。
- 良いの原則を遵守する単一の責任は、機能を変更するとき、あなたは大幅に他の機能への影響を減らすことができるかどう変化によるリスク低減は、変化が不可避です。
単一責任の原則は、オブジェクト指向のためのプログラミングのアイデアを、限りモジュールとして、単一責任の原則を適用するだけで、特定のではないことに留意すべきです。
シングル責任一見単純な、実際には、実際のアプリケーションプロセスでは、あなたが本当に責任拡張現象の多くを見つけるでしょう、遵守する、または単一責任の原則や方法の直接の違反をたどる完全に使用して、この時間は、現在の事業開発担当者に依存しますスキルレベルと時間の需要、どのような原則は、直接、多くの中小企業が、コードはビジネスヒープであることがわかります理由である、うまく機能を実現するためにしたくない、解決する他の場合には不十分なスキルレベルは確かにシンプルになる場合UPは、当然のことながら、これは紛れもないです、良い小さな会社コードが良いで書かれてあります。しかし、関係なく、少なくとも心はいくつかのソリューションがあることを知ってどのような方法解決するために、。
2、リヒターの置換原則（リスコフの置換原則）
リヒターの置換原則（リスコフの置換原則LSP）オブジェクト指向設計の基本原則の一つ。任意の基底クラスが表示されることができる場所でリヒターの置換原則、サブクラスが表示されることができるようになります。LSPは、派生クラスが基本クラスを置き換えることができた場合にのみ、機能のソフトウェアユニットは影響を受けません礎石は、基底クラスが実際に再利用できる多重化継承され、派生クラスは、基本クラスに基づいて新しい動作を追加することができます。リヒターの置換原則がある - 「オン - オフ」の原則を追加します。原則として抽象化における重要なステップである - 「閉じオープンは」達成するために。基底クラスとの継承関係は、抽象的、具体的な実現のサブクラスなので、リヒターの置換原則は、抽象を達成するための具体的な手順については、仕様です。
上記の概念を読んだ後は、なぜそれがリヒターを交換と呼ばれ、私のような多くの人があまりにも理解し、以上の好奇心はないと推定されていますか？理由：原理は、最初1988年に記載された、MIT某さんレーン（バーバラ・リスコフ）によって提示されたが来ます。
説明以下の解剖学：
定義1：T1 O1のそれぞれのオブジェクトタイプ、O2 T2は、オブジェクトタイプを持っている、すべての世代が置換されるときに、すべてがO1、O2オブジェクトP T1・プログラムを定義した、プログラムがPの動作を変更しないようであれば、その後型がタイプT2 T1のサブタイプです。
定義2：基底クラスへのすべての参照は、透過的にそのサブクラスのオブジェクトを使用する必要があります。
人気は簡単に言えば：サブクラスは親クラスの機能を拡張することができますが、元の関数の親クラスを変更することはできません。
それは意味が含まれています。
- サブクラスは抽象親クラスを実装することができるが、非抽象親クラスをカバーすることができません。
- サブクラスは、独自のユニークな方法を追加することができます。
- 親クラスのサブクラスのメソッドがオーバーロードされた場合、プロセスの前提条件よりリラックスした親クラスのメソッドよりも（すなわち、プロセスパラメータ）の入力パラメータ。[過負荷と書き換えとの間の区別に注意してください]
- 抽象親クラスの実装のサブクラスは、方法の事後条件（すなわち、値を返す）親より厳しい場合。
3.依存性逆転原理（依存性逆転原理）
いわゆる依存性逆転原理（依存反転原理）は、特定に依存しない、抽象的に依存することです。開口部の主要な原則を実装し、開口部とターゲットオブジェクト指向設計を閉じるの原理は、その原理は逆に依存しているオブジェクト指向設計の主要な手段であれば閉鎖は、抽象的で、抽象的な具体的な実現に由来します。
定義：高レベルのモジュールは、その抽象的に依存している必要があり、どちらも低レベルのモジュールに依存すべきではありません。抽象的には、詳細に頼るべきではありません。詳細は抽象的に依存しなければなりません。
プログラミングの抽象的要件、プログラミングを達成するためにではないが、このように、クライアントと実装モジュール間の結合を低減：という人気のポイント。
依存関係を転送するには、3つの方法がありますが、上記の例で使用した方法は、2つの他の発送方法があり、インタフェース転送です：渡されたコンストラクタを渡すとsetterメソッドは、私が使用した春のフレームワークを信じて、転送モードがに頼る不慣れではありません。
実際のプログラミングでは、我々は一般的に以下の3点を実行する必要があります。
- 可能な限り低いブロックは、抽象クラスまたはインタフェース、あるいはその両方を持っている必要があります。人々を[使用されるかもしれ]
- 抽象クラスまたはインタフェースがあり、できるだけ多くの変数の型を宣言します。
- 継承を使用する際に従うべきリヒター置換原則。
依存関係反転原理は、依存関係反転を理解し、インターフェイス指向プログラミングを理解するためのインターフェイスに私達のプログラミングの中核です。
4.インターフェイス分離原則（インタフェース分掌の原則）
原理は、文字通りある：界面分離複数の、単一のインターフェースを使用するよりも優れています。クラス間の結合を減少させることを意図し、そしてデザインパターンは、アップグレードするためとメンテナンスが容易で、大規模なソフトウェアアーキテクチャから、設計ソフトウェアです。したがって、上記複数回：結合を低減、依存性を低減します。
オリジナルの定義：クライアントがそれに頼るべきではありません、インタフェースはありません。このクラスの別のクラスへの依存は、最小のインターフェイスに基づいている必要があります。
インタフェースの分離原理を意味することである：単一のインタフェースの確立は、インターフェースを改良しようと、できるだけ少ないインタフェースメソッドを肥大化インターフェースを作成しないでください
ここでは、多くの人が前に単一責任原則の原則に非常によく似絶縁インターフェースを感じるだろう、そうではありません。まず、シングル責任原則は、デューティの主要な焦点であり、界面分離原理フォーカス分離インターフェースは異なり。全体的なフレームワークを構築するためのプログラムのために、主に抽象化するため、およびインターフェースインターフェースインターフェース偏析原理主制約;第二に、インタフェースおよびメソッド続い原理は、主にクラスに制約された単一の責任は、それはプログラムの実装および詳細を目的としています。
インターフェイスの制約のインターフェイス分離の原則を使用する場合は、次の点に注意してくださいするには：
- できるだけ小さくインターフェースが、制限があります。インタフェースは、プログラミングが稼いされていないという事実の柔軟性を向上させるために洗練することができますが、それが小さすぎる場合、それは設計を複雑に、インターフェースの過剰な数の原因となります。だから、中等度にしてください。
- 依存インターフェイスにサービスをカスタマイズし、唯一のメソッドを呼び出すためにクラスを公開することは、それを必要とし、それは方法が隠されている必要はありません。最低限の依存関係を確立するために、モジュール用にカスタマイズされたサービスを提供することに焦点を当てます。
- 結束を改善し、外部の相互作用を減らします。以上の方法とのインタフェースは、ほとんどのものを達成します。
適切でなければならない、インターフェイス分離の原則を使用して、インターフェイスのデザインが大きすぎたり小さすぎは良くありません。インタフェースの設計時間、正確にこの原則を実施するために考え、計画するだけでより多くの時間。
5.デメテル（知られている最小の原則）（デメテル原理）
エンティティは、エンティティと他の間の相互作用を最小限に抑える必要があり、独立した機能モジュールよう：なぜ、少なくとも既知の原理を呼び出し、それは言うことです。これは、ソフトウェアエンティティが他のエンティティとのわずかな相互作用であるべきです。したがって、モジュールが変更されたとき、他のモジュールの影響を最小化する、拡張ソフトウェアエンティティ間の通信を制限することであり、比較的容易になり、それは幅および深さの制限ソフトウェアエンティティ間の通信を必要とします。
定義：オブジェクトが他のオブジェクトの最小の理解に抑える必要があります。
問題の起源：クラスとクラスの間の密接な関係、クラスが変更された結合のより大きな程度は、別のクラスの影響も大きいです。
ソリューション：クラスとクラス間の結合を最小限に抑えます。
低カップリング、高凝集：プログラムはご連絡開始して以来、我々はソフトウェアプログラミングの一般的な原則を知っています。かまたはプロセス指向のプログラミングオブジェクト指向プログラミング、コードの再利用率を向上させるためにできるだけ低い個々のモジュール間のみの結合。しかし、低自明カップリングの利点は、どのように我々はプログラミングと低カップリングにそれを行うことができますか？それはデメテルの法則が行われるものです。
また、少なくとも既知の原則として知られているデメテルは、まず1987年にイアン・オランダアメリカノースイースタン大学によって提案されました。人気話すが、その依存クラスのクラスはよく知っています。これは、公衆によって提供される外部添加法、外の情報を漏らすことなく関係なく、内部ロジックにできるだけ多くの複雑なロジックは、クラスにカプセル化された方法を、依存クラスのために、ではありません。友人とのみ直接通信：デメテルは、より単純な定義があります。まずは、直接の友人であるかを説明しましょう：各オブジェクトは他のオブジェクトとの結合関係を持っている限り、2つのオブジェクト間の結合関係として、我々は、2つのオブジェクト間の友情を言います。多くの結合モード、依存、関連した、合成、重合。その中で、我々は今、クラスのローカル変数のうち、直接の友人ではありません、直接クラスの友人に出現メンバ変数、メソッドの引数、メソッドの戻り値を呼び出します。言い換えれば、なじみのないクラスは最高クラス内のローカル変数の形で表示されないように。
6.開閉原則（オープンクローズ原理）
それは開いて、拡張のためのオープンクローズの原則であるが、変更のため閉鎖しました。プログラムを展開する必要がある場合は、ホットスワップ可能なの効果を達成するために、既存のコードを変更しません。プログラムスケーラビリティを作るためには、メンテナンスとアップグレードの容易さ：だから、一つの文章にまとめました。私たちは、この効果を達成指向のプログラミング・インタフェースを必要とします。
定義されています。このようなクラス、モジュールや関数などのソフトウェアエンティティは、拡張のために開いている必要がありますが、変更のため閉鎖。
問題の起源は：変更、アップグレード、および保守またはその他の理由は、既存のソフトウェア・コードを変更する必要があるのため、ソフトウェアのライフサイクルでは、古いコードはエラーを導入している可能性や、私たちは全体の機能を再構築する必要がありますする可能性があり、そして、元のコードが再テストされている必要があり。
ソリューション：ソフトウェアを変更する必要がある場合は、ソフトウェアエンティティを拡張することにより、行動の変化を達成するためにではなく、既存のコードを変更することによって変化を達成してみてください。
オープニングとオブジェクト指向設計の原則を閉じるには、最も基本的な設計原理で安定的かつ柔軟なシステムを構築する方法で私たちを導きます。オープンとデザインパターンの6つの原則の原則を閉じて、それが唯一の拡張のためのオープンを教えてくれる、最もあいまいなの一つで定義されてもよいが、修正のため閉鎖が、最終的にどのように我々は拡張子を開くことができますが、変更のため閉鎖、と明示的に教えていませんでした。誰かが私に言った場合、「あなたはデザインが開閉の原則を遵守しなければならない作るときは、」以前、私は彼が何も言わなかった感じるが、それはのように見えると言います。オープン原則本当にボイド以来。
慎重に検討した後、多くの記事のデザインパターンを読めば、あなたが実際に見つける、我々は以前のデザインパターンの5つの原則に従うと、デザインパターンの23種類の使用は、開閉の原則に従うことです目指しています。言い換えれば、限り、私たちはフロント5のために良いの原則を順守するよう、ソフトウェアの設計は、当然この原則の開閉、開閉の原則に沿ったものである5の前に、より多くの「平均スコア」の5つの原則の遵守の以前のレベルのようなものですソフトウェアが良いの開閉の原則を遵守するように設計されていることを示す当然高く良い、平均の原則を遵守し、;前の5つの原則は、開閉の原則に悪い、そして良好なコンプライアンスを遵守した場合。
抽象を構築するためのフレームワーク、達成拡張詳細で：原則を閉じるこれは表現する一つの意味以上の何物でもありません。抽象優れた柔軟性と適応性なので、限り、抽象的、合理的として、安定したソフトウェアアーキテクチャままにすることができます。ソフトウェアの変数の詳細については、我々はそれを拡張するために、需要に応じた派生クラスを実装する必要があり、ソフトウェアを変更する必要があるとき、抽象実装クラスの生徒から拡張するために使用します。もちろん、私たちは抽象的ニーズの変化の仕事に前向きと予測可能性、合理的でなければならない場合に限ります。
ここでは、5つの原則を先に思い出すと、正確に私たちが教えている注意事項にのみ拡張の詳細を達成するために、抽象の枠組みを構築：単一責任の原則は、単一のクラスの任務を実装するために教えてくれる、リヒターの置換原則を教えてくれるではありません損傷の継承システム、依存性逆転の原則配向させるプログラミング・インタフェースを教えてくれる、インターフェイスの棲み分け原理は時に単一のインターフェイスの設計を効率化するために教えてくれる、デメテルは、結合を低減するために教えてくれる。開閉原理はマスターであり、彼は拡張のために開くために私たちに語ったが、修正のため閉鎖しました。
最後に、これらの6つの原則を遵守する方法について説明します。これら6つの原則に従い、全く問題はないではありませんが、問題のより少ない、つまり、我々は一般的に何のコンプライアンスがありません言いませんが、遵守のどのくらいの程度と言うこと。ものはあまりにも遠く、デザインパターンの6つの設計原理は同じである、我々の目的の6つの原則の開発は彼らと剛性遵守することはないです、実際の状況の使用における柔軟性が必要。それは良いデザインであっても、合理的な範囲内で、コンプライアンスのレベル限り。私たちは説明する図を使用しています。
あなたが合理的なのこの原則に従うならば、我々はポイントを描くの次元で、この原則の遵守の程度に応じて、各原則を表し、図中の各次元です、そして、この時点では赤い同心円の内側に落ちる必要があります。コンプライアンスが悪い場合、ポイントは小さな丸い内側になります。過度のコンプライアンス場合、ポイントは大円の外に落ちます。良い設計は、図面に反映され、それは、同心円状に六角形の6つの頂点であるべきです。
図において、1つの設計は、設計2は、それらが合理的な範囲の6つの原則に準拠している程度に、うまく設計に属し、3デザイン、デザイン4いくつかの欠点であるが、設計、基本的に許容されると、設計5は深刻原則の欠如が厳密に守られていない。遷移は6に準拠するように設計され、設計5および6は、設計を再構築することが急務に設計されています。