1 定義

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 abstractions.抽象不應該依賴細節；細節應該依賴抽象

針對介面編程，不要針對實作編程，

每個邏輯的實作都是由原子邏輯組成的，不可分割的原子邏輯就是低層模塊，原子邏輯的再組裝就是高層模塊
在Java語言中，抽象就是指介面或抽象類，兩者都是不能直接被實體化的
細節就是實作類，實作介面或繼承抽象類而產生的類就是細節，其特點就是可以直接被實體化，也就是可以加上一個關鍵字new產生一個物件，
依賴倒置原則在Java語言中的表現就是：
● 模塊間的依賴通過抽象發生，實作類之間不發生直接的依賴關系，其依賴關系是通過介面或抽象類產生的；
● 介面或抽象類不依賴于實作類；
● 實作類依賴介面或抽象類，

優點：可以減少類間的耦合性、提高系統穩定性，提高代碼可讀性和可維護性，可降低修改程式所造成的風險，

能不能把依賴弄對，要動點腦，依賴關系沒處理好，就會導致一個小改動影響一大片，
把依賴方向搞反，就是最典型錯誤，

最重要的是要理解“倒置”，而要理解什么是“倒置”，就要先理解所謂的“正常依賴”是什么樣的，
結構化編程思路是自上而下功能分解，這思路很自然地就會延續到很多人的編程習慣，按照分解結果，進行組合，所以，很自然地寫出下面這種代碼

這種結構天然的問題：高層模塊依賴于低層模塊：

• CriticalFeature是高層類
• Step1和Step2就是低層模塊，而且Step1和Step2通常都是具體類

很多人好奇了：step1和step2如果是介面，還有問題嗎？像這種流程式的代碼還挺常見的?
有問題，你無法確定真的是Step1和Step2，還會不會有Step3，所以這個設計依舊是不好的，如果你的設計是多個Step，這也許是個更好的設計，

在實際專案中，代碼經常會直接耦合在具體的實作上，比如，我們用Kafka做訊息傳遞，就在代碼里直接創建了一個KafkaProducer去發送訊息，我們就可能會寫出這樣的代碼：

我用Kafka發訊息，創建個KafkaProducer，有什么問題嗎？
我們需要站在長期角度去看，什么東西是變的、什么東西是不變的，Kafka雖然很好，但它并不是系統最核心部分，未來是可能被換掉的，

你可能想，這可是我的關鍵組件，怎么可能會換掉它？
軟體設計需要關注長期、放眼長期，所有那些不在自己掌控之內的東西，都有可能被替換，替換一個中間件是經常發生的，所以，依賴于一個可能會變的東西，從設計的角度看，并不是一個好的做法，

那該怎么做呢？這就輪到倒置了，

倒置，就是把這種習慣性的做法倒過來，讓高層模塊不再依賴低層模塊，
功能該如何完成？

計算機科學中的所有問題都可以通過引入一個間接層得到解決， All problems in computer science can be
solved by another level of indirection —— David Wheeler

引入一個間接層，即DIP里的抽象，軟體設計中也叫模型，這段代碼缺少了一個模型，而這個模型就是這個低層模塊在這個程序中所承擔角色，

2 實戰

重構

既然這個模塊扮演的就是訊息發送者的角色，那我們就可以引入一個訊息發送者（MessageSender）的模型：

有了訊息發送者這個模型，又該如何把Kafka和這個模型結合呢？
實作一個Kafka的訊息發送者：

這樣高層模塊就不像之前直接依賴低層模塊，而是將依賴關系“倒置”，讓低層模塊去依賴由高層定義好的介面，
好處就是解耦高層模塊和低層實作，

若日后替換Kafka，只需重寫一個MessageSender，其他部分無需修改，這就能讓高層模塊保持穩定，不會隨低層代碼改變，

這就是建立模型（抽象）的意義，

所有軟體設計原則都在強調盡可能分離變的部分和不變的部分，讓不變的部分保持穩定，
模型都是相對穩定的，而實作細節是易變的，所以，構建穩定的模型層是關鍵，

依賴于抽象

抽象不應依賴于細節，細節應依賴于抽象，

簡單理解：依賴于抽象，可推出具體編碼指導：

• 任何變數都不應該指向一個具體類
  如最常用的List宣告

• 任何類都不應繼承自具體類

• 任何方法都不應該改寫父類中已經實作的方法

當然了，如上指導并非絕對，若一個類特穩定，也可直接用，比如String 類，但這種情況很少！
因為大多數人寫的代碼穩定度都沒人家 String 類設計的高，

學習

首先定義一個學習者類

簡單的測驗類

假如現在又想學習Python，則面向實作編程就是直接在類添加方法

此類需經常改變，擴展性太差，Test 高層模塊, Learner 類為低層模塊，耦合度過高！

讓我們引入抽象：

現在就能將原學習者類的方法都消除

3 證明

采用依賴倒置原則可減少類間耦合，提高系統穩定性，降低并行開發引起的風險，提高代碼的可讀性和可維護性，

證明一個定理是否正確，有兩種常用方法：

• 順推證法
  根據論題，經過論證，推出和定理相同結論
• 反證法
  先假設提出的命題是偽命題，然后推匯出一個與已知條件互斥結論

反證法來證明依賴倒置原則的優秀！

論題

依賴倒置原則可減少類間的耦合性，提高系統穩定性，降低并行開發引起的風險，提高代碼的可讀性和可維護性，

反論題

不使用依賴倒置原則也可減少類間的耦合性，提高系統穩定性，降低并行開發引起的風險，提高代碼的可讀性和可維護性，

通過一個例子來說明反論題不成立！

• 司機駕駛奔馳車類圖
  

奔馳車可提供一個方法run，代表車輛運行：

司機通過呼叫奔馳車的run方法開動奔馳車

有車，有司機，在Client場景類產生相應的物件

現在來了新需求：張三司機不僅要開奔馳車，還要開寶馬車，又該怎么實作呢？
走一步是一步，先把寶馬車產生出來

寶馬車產生了，但卻沒有辦法讓張三開起來，為什么？
張三沒有開動寶馬車的方法呀！一個拿有C駕照的司機竟然只能開奔馳車而不能開寶馬車，這也太不合理了！在現實世界都不允許存在這種情況，何況程式還是對現實世界的抽象，

我們的設計出現了問題：司機類和奔馳車類緊耦合，導致系統可維護性大大降低，可讀性降低，
兩個相似的類需要閱讀兩個檔案，你樂意嗎？還有穩定性，什么是穩定性？固化的、健壯的才是穩定的，這里只是增加了一個車類就需要修改司機類，這不是穩定性，這是易變性，
被依賴者的變更竟然讓依賴者來承擔修改成本，這樣的依賴關系誰肯承擔？
證明至此，反論題已經部分不成立了，

繼續證明，“減少并行開發引起的風險”

什么是并行開發的風險？

并行開發最大的風險就是風險擴散，本來只是一段程式的例外，逐步波及一個功能甚至模塊到整個專案，一個團隊，一二十個開發人員，各人負責不同功能模塊，甲負責汽車類的建造，乙負責司機類的建造，在甲沒有完成的情況下，乙是不能完全地撰寫代碼的，缺少汽車類，編譯器根本就不會讓你通過！在缺少Benz類的情況下，Driver類能編譯嗎？更不要說是單元測驗了！在這種不使用依賴倒置原則的環境中，所有開發作業都是“單執行緒”，甲做完，乙再做，然后是丙繼續……這在20世紀90年代“個人英雄主義”編程模式中還是比較適用的，一個人完成所有的代碼作業，但在現在的大中型專案中已經是完全不能勝任了，一個專案是一個團隊協作的結果，一個“英雄”再牛也不可能了解所有的業務和所有的技術，要協作就要并行開發，要并行開發就要解決模塊之間的專案依賴關系，那然后呢？
依賴倒置原則隆重出場！

根據以上證明，若不使用依賴倒置原則就會加重類間的耦合性，降低系統的穩定性，增加并行開發引起的風險，降低代碼的可讀性和可維護性，

引入DIP后的UML：

建立兩個介面：IDriver和ICar，分別定義了司機和汽車的各個職能，司機就是駕駛汽車，必須實作drive()方法

介面只是一個抽象化的概念，是對一類事物的最抽象描述，具體的實作代碼由相應的實作類來完成

IDriver通過傳入ICar介面實作了抽象之間的依賴關系，Driver實作類也傳入了ICar介面，至于到底是哪個型號的Car，需要宣告在高層模塊，

ICar及其兩個實作類的實作程序：

業務場景應貫徹“抽象不應依賴細節”，即抽象（ICar介面）不依賴BMW和Benz兩個實作類（細節），因此在高層次的模塊中應用都是抽象：

Client屬于高層業務邏輯，它對低層模塊的依賴都建立在抽象上，java的表面型別是IDriver，Benz的表面型別是ICar，

在這個高層模塊中也呼叫到了低層模塊，比如new Driver()和new Benz()等，如何解釋？

java的表面型別是IDriver，是一個介面，是抽象的、非物體化的，在其后的所有操作中，java都是以IDriver型別進行操作，屏蔽了細節對抽象的影響，當然，java如果要開寶馬車，也很容易，只需修改業務場景類即可，

在新增加低層模塊時，只修改了業務場景類，也就是高層模塊，對其他低層模塊如Driver類不需要做任何修改，業務就可以運行，把“變更”引起的風險擴散降到最低，

Java只要定義變數就必然要有型別，一個變數可以有兩種型別：

• 表面型別
  在定義的時候賦予的型別
• 實際型別
  物件的型別，如java的表面型別是IDriver，實際型別是Driver，

思考依賴倒置對并行開發的影響，兩個類之間有依賴關系，只要制定出兩者之間的介面（或抽象類）即可獨立開發，而且專案之間的單元測驗也可以獨立地運行，而TDD（Test-Driven Development，測驗驅動開發）開發模式就是依賴倒置原則的最高級應用，

回顧司機駕駛汽車的例子：

• 甲程式員負責IDriver開發
• 乙程式員負責ICar的開發

兩個開發人員只要制定好了介面就可以獨立地開發了，甲開發進度比較快，完成了IDriver以及相關的實作類Driver的開發作業，而乙程式員滯后開發，那甲是否可以進行單元測驗呢？
根據抽象虛擬一個物件進行測驗：

只需要一個ICar介面，即可對Driver類進行單元測驗，
這點來看，兩個相互依賴的物件可分別進行開發，各自獨立進行單元測驗，保證了并行開發的效率和質量，TDD開發的精髓不就在這？
TDD，先寫好單元測驗類，然后再寫實作類，這對提高代碼的質量有非常大的幫助，特別適合研發類專案或在專案成員整體水平較低情況下采用，

抽象是對實作的約束，對依賴者而言，也是一種契約，不僅僅約束自己，還同時約束自己與外部的關系，其為保證所有細節不脫離契約范疇，確保約束雙方按既定契約（抽象）共同發展，只要抽象這根基線在，細節就脫離不了這個圈圈，

4 依賴

依賴可以傳遞，A物件依賴B物件，B又依賴C，C又依賴D……
只要做到抽象依賴，即使是多層的依賴傳遞也無所畏懼！

物件的依賴關系有如下傳遞方式：

構造器傳遞

在類中通過構造器宣告依賴物件，建構式注入

4.2 Setter傳遞

在抽象中設定Setter方法宣告依賴關系,Setter依賴注入

4.3 介面宣告依賴物件

在介面的方法中宣告依賴物件

5 最佳實踐

依賴倒置原則的本質就是通過抽象（介面或抽象類）使各個類或模塊的實作彼此獨立，不互相影響，實作模塊間的松耦合，

DIP指導下，具體類能少用就少用，
具體類我們還是要用的，畢竟代碼要運行起來不能只依賴于介面，那具體類應該在哪用？
這些設計原則，核心關注點都是一個個業務模型，此外，還有一些代碼做的作業是負責組裝這些模型，這些負責組裝的代碼就需要用到一個個具體類，

做這些組裝作業的就是DI容器，因為這些組裝幾乎是標準化且繁瑣，如果你常用的語言中，沒有提供DI容器，最好還是把負責組裝的代碼和業務模型放到不同代碼，

DI容器另外一個說法叫IoC容器，Inversion of Control，你會看到IoC和DIP中的I都是inversion，二者意圖是一致的，

依賴之所以可注入，是因為我們的設計遵循 DIP，而只知道DI容器不了解DIP，時常會出現讓你覺得很為難的模型組裝，根因在于設計沒做好，

DIP還稱為好萊塢規則：“Don’t call us, we’ll call you”，“別呼叫我，我會調你的”，這是框架才會有的說法，有了一個穩定抽象，各種具體實作都應由框架去呼叫，

為什么說一開始TransactionRequest是把依賴方向搞反了？因為最初的TransactionRequest是一個具體類，而TransactionHandler是業務類，

我們后來改進的版本里引入一個模型，把TransactionRequest變成了介面，ActualTransactionRequest 實作這個介面，TransactionHandler只依賴于介面，而原來的具體類從這個介面繼承而來，相對來說，比原來的版本好一些，

對于任何一個專案而言，了解不同模塊的依賴關系是一件很重要的事，你可以去找一些工具去生成專案的依賴關系圖，然后，你就可以用DIP作為一個評判標準，去衡量一下你的專案在依賴關系上表現得到底怎么樣了，很有可能，你就找到了專案改造的一些著力點，

理解了 DIP，再來看一些關于依賴的討論，我們也可以看到不同的角度，
比如，回圈依賴，回圈依賴就是設計沒做好的結果，把依賴關系弄錯，才可能回圈依賴，先把設計做對，把該有的介面提出來，就不會回圈了，

我們怎么在專案中使用這個規則呢？只要遵循以下的幾個規則就可以：

• 每個類盡量都有介面或抽象類，或者抽象類和介面兩者都具備
  這是依賴倒置的基本要求，介面和抽象類都是屬于抽象的，有了抽象才可能依賴倒置

• 變數的表面型別盡量是介面或者是抽象類
  很多書上說變數的型別一定要是介面或者是抽象類，這個有點絕對化了

  • 比如一個工具類，xxxUtils一般是不需要介面或是抽象類的
  • 如果你要使用類的clone方法，就必須使用實作類，這個是JDK提供的一個規范，

• 任何類都不應該從具體類派生
  如果一個專案處于開發狀態，確實不應該有從具體類派生出子類的情況，但這也不是絕對的，因為人都是會犯錯誤的，有時設計缺陷是在所難免的，因此只要不超過兩層的繼承都是可以忍受的

• 盡量不要覆寫基類方法
  如果基類是一個抽象類，而且這個方法已經實作了，子類盡量不要覆寫
  類間依賴的是抽象，覆寫了抽象方法，對依賴的穩定性會產生一定的影響

• 結合里氏替換原則使用
  父類出現的地方子類就能出現， 介面負責定義public屬性和方法，并且宣告與其他物件的依賴關系，抽象類負責公共構造部分的實作，實作類準確的實作業務邏輯，同時在適當的時候對父類進行細化，

到底什么是“倒置”

依賴正置就是類間的依賴是實實在在的實作類間的依賴，也就是面向實作編程，這也是正常人的思維方式，我要開奔馳車就依賴奔馳車，我要使用筆記本電腦就直接依賴筆記本電腦，
而撰寫程式需要的是對現實世界的事物進行抽象，抽象的結果就是有了抽象類和介面，然后我們根據系統設計的需要產生了抽象間的依賴，代替了人們傳統思維中的事物間的依賴，“倒置”就是從這里產生的

依賴倒置原則是實作開閉原則的重要途徑，依賴倒置原則沒有實作，就別想實作對擴展開放，對修改關閉，
只要記住面向介面編程就基本上抓住了依賴倒置原則的核心，

依賴倒置原則說的是：
1.高層模塊不應依賴于低層模塊，二者都應依賴于抽象
2.抽象不應依賴于細節，細節應依賴于抽象
總結起來就是依賴抽象（模型），具體實作抽象介面，然后把模型代碼和組裝代碼分開，這樣的設計就是分離關注點，將不變的與不變有效的區分開

防腐層可以解耦對外部系統的依賴，包括介面和引數，防腐層還可以貫徹介面隔離的思想，以及做一些功能增強(加快取,異步并發取值)，

參考

• 設計模式之嬋