開閉の原則

クラス、モジュール、関数のようなソフトウェアの実体は、拡張に対してオープンであり、修正に対してはクローズであるべきです！

コンテキスト

一般的に、システムが比較的安定している場合、抽象インターフェースを実装することでDaoクラスが完成しますが、Daoクラスに対する実装が満足できない場合。元のDaoをベースに新しいメソッドやモジュールを追加する必要があります。インターフェイスの排他的な使用は当然簡単ですが、パブリックインターフェイスやインターフェイスの明確な機能のために、各変更は、システムとアーキテクチャの安定性を分析する必要があり、そう気軽に変更することはできません！

適用

解析

ICourseとjavaCourseは、インターフェイスの下に通常のビジネスのシステム設計の始まりであり、初期システムとして、その検討の関係の実装は、完全かつ十分なされており、今ビジネスの拡大のため、もはや満足されていない、現在のメソッドを拡張する必要があります！一般的には、一般的なコードを変更するには、もはや行くが、クラスの現在の実装は、必要に応じてコードのオーバーロードの元のメソッドを拡張することです！

拡張

クラスを拡張する場合、インターフェイス参照を使用してクラスを拡張するメソッドを 呼び出します。 これは、ランタイム・ポリモーフィズムを利用することで機能します。親参照がサブクラスオブジェクトを指す場合、親オブジェクトは宣言されますが、サブクラスオブジェクトはコンパイルされ、サブクラスがインスタンス化されると、親クラスも一緒にコンパイルされます！したがって、staticを呼び出すために親参照を使用する場合、static変数は、親クラスに属し、メンバメソッドを呼び出すときに、親参照は、親クラスに属しているため、メソッドのサブクラスを呼び出すことはできません、親クラスのメソッドのみを呼び出すことができます。サブクラスのメソッドを呼び出す唯一の方法は、親の宣言は、次のように、サブクラスのオブジェクトに強制される場合です。

解析

インターフェース・クラス参照 サブクラス宣言を指します。呼び出される静的リソースは、インターフェース・クラスの実装クラスです。

依存関係の逆転の原理

上位モジュールは下位モジュールに依存すべきではありません！

コンテキスト

依存関係の逆転は特殊なケースですが、効果の変化は最も強力なものの1つであり、インターフェースプログラミングの古典に属します！ 一般的に、学習などのユーザーの能力に対して、ユーザークラスを定義し、ユーザークラスにメンバメソッドを与えることでこの振る舞いを実装することができます。しかし、ユーザークラスの継続的な発展によって、ユーザークラスはそれぞれの必要性に対してメソッドを持ち、ユーザークラスを一度修正したり拡張したりすると、最終的な結果は必然的にシステムクラスの爆発につながります。

ユーザーは、学習や学習数学、学習言語、英語の間の関係を学ぶなど、実装の特定のタイプに属する能力を拡張する場合は、ユーザークラスは、インターフェイスのこのタイプを参照するように、学習の種類の抽象化のタイプを学ぶことができます。たとえば、ユーザークラスは、パラメトリックコンストラクタまたはsetXXX（学習インターフェイスの種類xxxの）インターフェイスを指すように、学習インターフェイスの種類の実装のための学習のさまざまなタイプのために、ポリモーフィック機能の使用を参照するように、ユーザーと学習の種類は、低結合のためのインターフェイスの学習の種類を達成するために学習の種類から切り離されます。

解析

凡例のこの図は、ICourseとUserの直接リンクの関係を無視する必要がある、凡例を通じて、ICourseとUserクラスのみ集約関係を持っていることがわかりますし、インターフェイスクラスの実装では、サブコースは、ビジネスのニーズと拡張する自由をたどることができます！ ステートメントに直接渡す必要性のUserクラスは、対応すると呼ばれることができます！次のように：

単一責任の原則

クラス替えの原因は1つだけではありません。

コンテキスト

単一の責任は、クラスレベル、メソッドレベル、およびインターフェイスレベルで単一の関数があることを意味します。クラスでは、デューティ1とデューティ2の変更は、同じクラスのクラスに影響を与えるし、長いときに発生する可能性がありますあまりにも多くの責任は、1つの髪を引っ張ると、全身に影響を与える、システムのカップリングが高すぎると維持することは容易ではありません！

インターフェース・レベル

単一任務とは、インターフェイスがすべて同じ種類のインターフェイスに属することを意味し、インターフェイスを分割するのは少なすぎず、多すぎず、任務に従ってください！そして、完成した後、依存関係の逆転の原則に基づいて、修正参照を実行することができます

メソッドレベル

単一かつ明確なメソッドと関数のサービス。開発において、インターフェースとメソッドの単一責任は可能な限り維持され、クラスの単一責任はケースバイケースで分析されます！

インターフェース分離の原則

複数の関数のメソッドをひとまとめにしたインターフェイスを使うのではなく、複数の関数に特化したインターフェイスを使いましょう！あるクラスから別のクラスへの依存関係は、最小限のインターフェースで構築すべきです。

以下のことに注意してください。

インターフェイスの分離の原則は、理論的にはインターフェイスの洗練された、しかし、インターフェイスのあまりにも多くの洗練された必然的にコードのあまりにも多くの複雑さにつながるので、インターフェイスを作成するプロセスでは、あまりにも多くのインターフェイス宣言を防ぐためですが、また、メソッドの本体内部のインターフェイスを防ぐためにあまりにも多く、いくつかのクラスにつながる空の実装が表示されます！

現実

私はそれを言いたくはありませんが、このインターフェイスは、多くの場合、デフォルトで最も使用され、現在の3層アーキテクチャは、必ずこの設計に準拠してインターフェイスを行うモジュールとして "機能 "することです！

上記の3つのインターフェイスは、すべて動物の種類に基づいて、以下の統合インターフェイスの中から分割されています！

ディミトリの原理

オブジェクトは、他のオブジェクトに関する知識を最小限に保つべきです。オブジェクトは友人のオブジェクトを監視するだけでよく、あとは仲介クラスに任せればよいのです！

コンテキスト

どのようなクラスであっても、クラスの参照やオブジェクト宣言が多すぎると、そのクラスは参照先のクラスと強く結合することになり、コードの保守性や拡張性に大きな悪影響を及ぼします。したがって、クラスが他のクラスを参照する場合、必要でなければ、そのクラスをできるだけ紹介しないようにします。例えば、継承をあまり使わず、集約や結合を多用するのも同じ理由です！

注：ディミットは、主に以下の点に着目して、境界、注意点を指定しています：

クラスのメンバ変数、インパラメータ、アウトパラメータに関与するオブジェクトは、すべてそのクラスの友人です。そのため、メソッド本体は他の友達ではないクラスとなるべく会話しないようにする必要があります！

リヒターの置き換え

型T1のすべてのオブジェクトo1に対して、型T2のオブジェクトo2が存在し、オブジェクトohがすべてo2に置き換えられても、T1で定義されたすべてのプログラムPの振る舞いが変わらないような場合、型T2のサブタイプはT1を噛みます！

拡張

親クラスを使用するソフトウェア・エンティティは、その子クラスにも適用されなければなりません。親クラスへのすべての参照は、その子のオブジェクトを透過的に使用することができなければならず、子クラスはプログラム・ロジックが変更されないまま、親クラスを置き換えることができます！

リヒターの置換は、オープン・クローズド原則を拡張したもので、親クラスがチーム化されたときに親クラスを拡張するためのいくつかの原則を確立し、継承の拡散を制限するものです！

RI原則は、基本クラスを直接変更するのではなく、新しいビジネス要件を満たすために既存のクラスやインタフェースを拡張することをサポートします。しかし、RI置換原則は親クラスのオーバーライドをサポートしておらず、オーバーロードをサポートしています：

この3つのルールを組み合わせると、リボン置換がオーバーロードを比較的うまくサポートしていることがわかります。また、それにはいくつかの要件があります。

サブクラスのメソッドが親メソッドをオーバーライドする場合、メソッドの前提条件、つまりメソッドの入力は、親メソッドの入力パラメータよりも緩やかでなければなりません！サブクラスの引数が親と同じ場合はオーバーライドになり、入力パラメータ・タイプが親よりも小さい場合は、親メソッドは決して実行されません！

サブクラスのメソッドが親クラスのメソッドを実装する場合、メソッドの後条件は親クラスよりも厳しいか等しくなければなりません！

合成/再利用の原則

再利用のために、継承ではなくオブジェクトの組み合わせを使用するようにしてください。

再利用機能を達成するために、組み合わせ/集約関係を介して最初の間の関係のための設計指向のプロセスでは、継承と再利用を達成するために関係の実装が続きます。集約の組み合わせは、システムをより柔軟にすることができますが、クラスのバインディング間の関係の継承は、結合の高度な原因となるため、クラス間の結合の程度を低減します。

継承の再利用は、ホワイトボックス操作として知られているサブクラスの動作に親クラスの内部の詳細を公開することは容易であるクラスのカプセル化を破壊します。また、親クラスから継承されたサブクラスは、基本的にメソッドの静的な実装に基づいており、親クラスが変更されると、サブクラスも変更に合わせて変更する必要があります。クラス間の柔軟性は十分ではありません！

注入

組み合わせ

コンビネーションとは、同じライフサイクルを持つ複数のオブジェクトをまとめたもので、メインクラスはサブクラスへの参照などの情報を保持し、サブクラスのいずれかに問題が発生したり、失われたりすると、メインクラスに影響が及びます！

集約

メインクラスは、おそらくsetメソッドを通してサブクラスへの呼び出しを維持し、サブクラスがなくなってもメインクラスは影響を受けません！