依賴倒置原則

「● 高層模組不應該依賴低層模組，兩者都應該依賴其抽象；

● 抽象不應該依賴細節；

● 細節應該依賴抽象。」

翻譯一下

「● 模組間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過介面或抽象類產生的；

● 介面或抽象類不依賴於實現類；

● 實現類依賴介面或抽象類」

「只要做到抽象依賴，即使是多層的依賴傳遞也無所畏懼！」

「物件的依賴關係有三種方式來傳遞，如下所示。」

「1.建構函式傳遞依賴物件」：建構函式注入

「2.setter方法傳遞依賴物件」：setter依賴注入

「3.介面宣告依賴物件：介面注入

「● 每個類盡量都有介面或抽象類，或者抽象類和介面兩者都具備

這是依賴倒置的基本要求，介面和抽象類都是屬於抽象的，有了抽象才可能依賴倒置。

● 變數的表面型別盡量是介面或者是抽象類」

「● 任何類都不應該從具體類派生

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

「● 盡量不要覆寫基類的方法

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

● 結合黎克特制替換原則使用

在第2章中我們講解了黎克特制替換原則，父類出現的地方子類就能出現，再結合本章的講解，我們可以得出這樣乙個通俗的規則：介面負責定義public屬性和方法，並且宣告與其他物件的依賴關係，抽象類負責公共構造部分的實現，實現類準確的實現業務邏輯，同時在適當的時候對父類進行細化」

「在專案中，大家只要記住是「面向介面程式設計」就基本上抓住了依賴倒置原則的核心。」

「我們在實際的專案中使用依賴倒置原則時需要審時度勢，不要抓住乙個原則不放，每乙個原則的優點都是有限度的，並不是放之四海而皆準的真理，」

「所以別為了遵循乙個原則而放棄了乙個專案的終極目標：投產上線和盈利。作為乙個專案經理或架構師，應該懂得技術只是實現目的的工具，惹惱了頂頭上司，設計做得再漂亮，**寫得再完美，專案做得再符合標準，一旦專案虧本，產品投入大於產出，那整體就是扯淡！你自己也別想混得更好！」