#依賴倒置原則定義
依賴倒置原則(Dependence Inversion Principle ,DIP)定義如下：
High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstracts.
翻譯過來為：
- 高層子產品不應該依賴低層子產品，兩者都應該依賴抽象
- 抽象不應該依賴細節
- 細節應該依賴抽象
也可以說高層子產品，低層子產品，細節都應該依賴抽象
每一個邏輯的實作都是由顆粒原子邏輯組成的，顆粒原子邏輯就是低層子產品，而顆粒原子邏輯組成的子產品就是高層子產品。在java語言中，抽象就是接口或抽象類，兩都都是不能直接被執行個體化的，細節就是實作類，實作接口或繼承抽象類而産生的類就是細節，兩者都可以直接被執行個體化。
依賴倒置原則在java語言中，表現是：
- 子產品間的依賴通過抽象發生，實作類之間不發生直接的依賴關系，其依賴關系是通過接口或抽象類産生的。
- 接口或抽象類不依賴實作類
- 實作類依賴接口或抽象類
更加精簡的定義就是“面向接口程式設計”—OOD(Object-Oriented Design，面向對象設計)的精髓之一。
#依賴倒置原則的好處
采用依賴倒置原則可以減少類間的耦合性，提高系統的穩定，降低并行開發引起的風險，提高代碼的可讀性和可維護性。
#為什麼我們要符合依賴倒置原則
我們通過一個例子說明依賴倒置原則對于開發有上面的好處。
大家都喜歡閱讀，閱讀文學經典滋潤自己的内心心靈，下面是小明同學閱讀文學經典的一個類圖：
文學經典的源代碼：
//文學經典類
public class LiteraryClassic{
//閱讀文學經典
public void read(){
System.out.println("文學經典閱讀，滋潤自己的内心心靈");
}
}
小明類：
//小明類
public class XiaoMing{
//閱讀文學經典
public void read(LiteraryClassic literaryClassic){
literaryClassic.read();
}
}
場景類：
public class Client{
public static void main(Strings[] args){
XiaoMing xiaoming = new XiaoMing();
LiteraryClassic literaryClassic = new LiteraryClassic();
//小明閱讀文學經典
xiaoming.read(literaryClassic);
}
}
看，我們的實作，小明同學可以閱讀文學經典了。
小明同學看了一段文學經典後，忽然他想看看看小說來放松一下自己,我們實作一個小說類：
小說類源代碼
//小說類
public class Novel{
//閱讀小說
public void read(){
System.out.println("閱讀小說，放松自己");
}
}
現在我們再來看代碼，發現XiaoMing類的read方法隻與文學經典LiteraryClassic類是強依賴，緊耦合關系，小明同學竟然閱讀不了小說類。這與現實明顯的是不符合的，代碼設計的是有問題的。那麼問題在那裡呢？
我們看小明類，此類是一個高層子產品，并且是一個細節實作類，此類依賴的是一個文學經典LiteraryClassic類，而文學經典LiteraryClassic類也是一個細節實作類。這是不是就與我們說的依賴倒置原則相違背呢？依賴倒置原則是說我們的高層子產品，實作類，細節類都應該是依賴與抽象，依賴與接口和抽象類。
為了解決小明同學閱讀小說的問題，我們根據依賴倒置原則先抽象一個閱讀者接口,下面是完整的uml類圖：
IReader接口：
public interface IReader{
//閱讀
public void read(IRead read){
read.read();
}
}
再定義一個被閱讀的接口IRead:
public interface IRead{
//被閱讀
public void read();
}
再定義文學經典類和小說類：
文學經典類：
//文學經典類
public class LiteraryClassic implements IRead{
//閱讀文學經典
public void read(){
System.out.println("文學經典閱讀，滋潤自己的内心心靈");
}
}
小說類:
//小說類
public class Novel implements IRead{
//閱讀小說
public void read(){
System.out.println("閱讀小說，放松自己");
}
}
再實作小明類：
//小明類
public class XiaoMing implements IReader{
//閱讀
public void read(IRead read){
read.read();
}
}
然後，我們再讓小明分别閱讀文學經典和小說：
Client:
public class Client{
public static void main(Strings[] args){
XiaoMing xiaoming = new XiaoMing();
IRead literaryClassic = new LiteraryClassic();
//小明閱讀文學經典
xiaoming.read(literaryClassic);
IRead novel = new Novel();
//小明閱讀小說
xiaoming.read(novel);
}
}
至此，小明同學是可以閱讀文學經典，又可以閱讀小說了，目的達到了。
為什麼依賴抽象的接口可以适應變化的需求？這就要從接口的本質來說，接口就是把一些公司的方法和屬性聲明，然後具體的業務邏輯是可以在實作接口的具體類中實作的。是以我們當依賴對象是接口時，就可以适應所有的實作此接口的具體類變化。
#依賴的三種方法
依賴是可以傳遞，A對象依賴B對象，B又依賴C，C又依賴D，…，依賴不止。隻要做到抽象依賴，即使是多層的依賴傳遞也無所謂懼。
對象的依賴關系有三種方式來傳遞：
##構造函數傳遞依賴對象
在類中通過構造函數聲明依賴對象，按照依賴注入的說法，這種方式叫做構造函數注入：
構造函數注入：
//小明類
public class XiaoMing implements IReader{
private IRead read;
//構造函數注入
public XiaoMing(IRead read){
this.read = read;
}
//閱讀
public void read(){
read.read();
}
}
##Setter方法傳遞依賴對象
在類中通過Setter方法聲明依賴關系，依照依賴注入的說法，這是Setter依賴注入：
//小明類
public class XiaoMing implements IReader{
private IRead read;
//Setter依賴注入
public setRead(IRead read){
this.read = read;
}
//閱讀
public void read(){
read.read();
}
}
##接口聲明依賴
在接口的方法中聲明依賴對象，在為什麼我們要符合依賴倒置原則的例子中，我們采用了接口聲明依賴的方式，該方法也叫做接口注入。
#依賴倒置原則的經驗
依賴倒置原則的本質就是通過抽象(接口或抽象類)使各個類或子產品的實作彼此獨立，不互相影響，實作子產品間的松耦合。我們在項目中使用這個原則要遵循下面的規則：
- 每個類盡量都有接口或者抽象類，或者抽象類和接口兩都具備
- 變量的表面類型盡量是接口或者抽象類
- 任何類都不應該從具體類派生
-
盡量不要覆寫基類的方法
如果基類是一個抽象類，而這個方法已經實作了，子類盡量不要覆寫。類間依賴的是抽象，覆寫了抽象方法，對依賴的穩定性會有一定的影響。
-
結合裡氏替換原則使用
裡氏替換原則：父類出現的地方子類就能出現。結合本章我們得出了一個通俗的規則：接口負責定義public屬性和方法，并且聲明與其他對象的依賴關系。抽象類負責公共構造部分的實作，實作類準确的實作業務邏輯，同時在适當的時候對父類進行細化。
依賴倒置原則是6個設計原則中最難以實作的原則，它是實作開閉原則的重要方法，在項目中，大家隻要記住是"面向接口程式設計"就基本上是抓住了依賴倒置原則的核心了。
參考：
設計模式之禅 秦小波著 機械工業出版社