依存関係逆転の原則（依存反転Priiciple、DIP）
入門
高レベルのモジュールは、低レベルのモジュールに依存してはいけません。どちらも、抽象化に依存しなければなりません。抽象化は、詳細に依存してはいけません。Detatilsは抽象に依存しなければならない。
翻译过来有是三个意思：
1.層モジュールは、両方の抽象に依存する必要があり、基礎となるモジュールに依存しないでください。
2.抽象は詳細に依存するべきではありません。
3.詳細は抽象的に依存しなければなりません。
Javaでは、パフォーマンスは次のとおりです。
1.モジュール間の依存関係は、抽象化を介して生じるオフ依存実装クラスとの間で直接発生しないはずの、インターフェースの依存関係が使用されるか、または抽象クラスを生成しなければなりません。
2.インターフェイスや抽象クラスは、実装クラスに依存してはいけません。
3.依存インターフェイスまたはクラスは抽象クラスを実装する必要があります。
依存関係逆転の原則設計哲学は以下のとおりです。変動のインターンシップクラスと比較すると、抽象はるかに安定。デザインフレームワークは、抽象的に基づいている必要があり、このように、事業の安定性を向上させることができます。
フレームにおいて、効果は抽象仕様を開発するために使用され、具体的な詳細は、クラスを達成することです。
アプリケーション例
車を運転するためのドライブウェイを持つクラスのオブジェクトドライバージョー・スミス（ZS）が、あります。
public class Dependence1 {
public static void main(String[] args) {
Driver zs = new Driver();
Benz benz = new Benz();
zs.drive(benz);
}
}
class Driver {
public void drive(Benz benz) {
benz.run();
}
}
class Benz {
public void run() {
System.out.println("奔驰汽车发动...");
}
}
//经过艰苦奋斗，张三同志买了一辆宝马汽车
class BMW {
public void run() {
System.out.println("宝马汽车发动...");
}
}これまでのところ、それは非常に素晴らしい、正常な機能が達成されるに見えますが、機能は、特定のカテゴリベンツは、後で拡張のためにトラブルをもたらしており、実現に基づいているため：例えば、同志ジョー・スミスハードワークを、彼らが買って、 BMW（BMW）が、駆動方式のドライバクラスに応じて、同志ジョー・スミスは、新しいBMWを購入する駆動することはできません。これは非常に深刻なロジックです：限り、運転免許証を持っているように、メルセデス・ベンツとBMWは運転することができるはずです。
改善点：
明らかに、駆動方式のドライバクラスは、車の特定のブランドに依存してはならない、と車は一般的な文脈によるものです。したがって、2つの新しいインタフェース：
IdriverとICAR、車が車を運転され、ドライバの機能と車を定義します。具体的なコードは次のよう：
public class Dependence2 {
public static void main(String[] args) {
IDriver zs = new Driver();
ICar benz = new Benz();
zs.drive(benz);
ICar bmw = new BMW();
zs.drive(bmw);
}
}
interface ICar {
//是汽车都应该具备的功能
public void run();
}
class Benz implements ICar {
@Override
public void run() {
System.out.println("奔驰汽车发动...");
}
}
class BMW implements ICar {
@Override
public void run() {
System.out.println("宝马汽车发动...");
}
}
interface IDriver {
//是司机就应该会开车，不管是什么车
public void drive(ICar iCar);
}
class Driver implements IDriver {
@Override
public void drive(ICar iCar) {
iCar.run();
}
}（例えば新規などの拡張ビジネス・ロジック内のドライバタイプIDriverの座面は、ベンツとBMW ICARがそうするように、ある面型;クラスDependence2層モジュールとしてデモ、抽象的に基づいて、基礎となるモジュールへの依存で車ミニ）は、単にビジネスシーンクラス（トップモジュール）を変更すると、その上の基礎となるモジュールドライバベンツとに与える影響はありません場合。
三つの形式の依存性
依存の3つの方法でファッション：インタフェースの依存性は、setterメソッドおよびコンストラクタは依存依存しています。下記の詳細：
1.インタフェースの依存
名前が示唆するように、インタフェース、改良上で詳述コードによって射出依存的です。
2.setter方法は依存しています
抽象的に定義されたsetterメソッドは、この方法は、いわゆるセッターに依存しています。
次のようにデモは次のとおりです。
interface IDriver {
//setter方式注入
public void setICar(ICar iCar);
}
class Driver implements IDriver {
private ICar iCar;
@Override
public void setICar(ICar iCar) {
this.iCar = iCar;
}
}3.構造が依存しています
これは、コンストラクタで渡されたドライバー、理解することは比較的容易でありICARの特定のタイプです。
class Driver implements IDriver {
private ICar iCar;
public Driver(ICar iCar) {
this.iCar =iCar;
}
}注意事項や詳細
プロジェクトでは、基本となるクラスモジュールは、抽象クラスまたはインタフェース、あるいはその両方を持っている必要があり、
抽象型である必要があり、変数を宣言し、プロジェクトの安定性改善に役立たせていただきます。
どんな種類が特定のクラスから派生してはならない。
しないようにしようとします使用と併せて、蓄積を書き換える方法「リヒター置換原則。」