名字很難了解,具體展現表現在三個方面
1:子產品間的依賴通過抽象類發生,實作類之間不能發生直接的依賴關系,其依賴關系是通過接口或抽象類産生的。
2:接口或抽象類不能依賴于實作類。
3:實作類依賴接口或者抽象類。
簡而言之就表現為“面向接口程式設計”,OOD。
可以用都很熟悉的司機開車案例來了解
很多時候為了加快速度,都會這麼寫:
司機類,有一個方法是開車drive,需要一輛寶馬車
String name;
public void drive(BaoMaCar mBaoMa){
mBaoMa.run();
}
}
寶馬車,有一個方法是運作run。
public class BaoMaCar {
public void run(){
Log.e("fig","寶馬開始行駛");
}
}
執行
public class Env {
public static void main(String[] args) {
Driver mDriver = new Driver();
mDriver.drive(new BaoMaCar());
}
}
結果就是寶馬車開始行駛,這樣開發速度很快,
但是很不利于後續程式的擴充,你想,如果有一天司機大叔又買了輛奔馳呢?是不是不光要建立一個奔馳車類,還要修改司機類的構造。新增開車的司機也會有這種麻煩。是以我們可以根據第一條原則----子產品間的依賴通過抽象類發生,實作類之間不能發生直接的依賴關系,對代碼進行重新設計,如下:新增兩個接口,司機和車,如下:

司機的接口
public interface IDriver {
void drive(ICar mCar);
}
生産車的接口
public interface ICar {
void run();
}
運作時:
public class Env {
public static void main(String[] args) {
IDriver mDriver = new LiSiDriver();
mDriver.drive(new BaoMaCar());
mDriver.drive(new BenChiCar());
Log.e("fig","------------------------------");
IDriver mDriver2 = new ZhangSanDriver();
mDriver2.drive(new BenChiCar());
mDriver2.drive(new BaoMaCar());
}
}
運作結果如下:
這樣就通過接口來實作了程式的可擴充性和易于維護性,遵循了依賴倒置原則,以後買了新車後隻需實作ICar接口,就可以直接在Env中使用,而不必去修改司機類,同樣,雇傭了新的司機隻需實作IDriver接口,然後就可以在Env中直接使用,不會影響已經寫過的代碼。