依賴倒置原則（
dependence inversion principle）
定義：
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.
即：高層模組不應該依賴低層模組，二者都應該依賴其抽象。抽象不應該依賴細節，細節應該依賴抽象。
高層模組與低層模組：
高層與低層的區分是相對的，不固定的，如果從「功能」角度出發，把「功能」看成是乙個中國盒子，那麼外面的盒子相對裡面的盒子就是高層，裡面的盒子相對外面的盒子就是低層。
抽象：
抽象是什麼？抽象就是抽象，因為抽象本身是不存在的，它恰恰與具象相反。在程式設計之外的世界，抽象通常作為乙個動詞來使用，抽象的意思是：遮蔽事物的不一致性，抽取出共性的過程。就像物理學解題中，經常把一些物體抽象成乙個質點。
這裡的抽象就被用作乙個動詞，但在程式設計的世界中，因為語言差異，把
abstract
和abstraction
都翻譯成抽象，很明顯，
abstraction
是名詞的意思。再看之前依賴倒置原則的英文定義，用的是名詞。那麼在程式設計世界中，抽象的定義就應該是「遮蔽差異，抽取共性後的構造結果」。
舉個現實生活的例子，汽車就是轎車，越野車，跑車遮蔽各種車型差異後的抽象，而且被抽象的物件也可以是抽象本身，比如轎車也是大眾轎車，福特轎車，豐田轎車的抽象。再想想之前舉的「中國盒子」的例子，是不是有一種「太極生兩儀，兩儀生八卦，八卦生永珍」無窮無盡的奇妙感覺？而在物件導向中，抽象可以是類，屬性，也可以是行為（介面本身可以視為一種類）。
細節：理解了抽象就很好理解細節了，細節就是抽象的實現。
理解了定義的各部分後，我們可以總結得出，所謂的「依賴倒置原則」，可以理解成為：高層模組使用低層模組的抽象，低層模組實現抽象。抽象只考慮共性，由於所謂共性之中本身存在細節上的差異，所以抽象的時候，不應該考慮這些差異，但是低層模組實現抽象的時候，必須遵循產出是抽象出來的共性這一點。
英文定義直譯過來有時候很難理解，所以需要轉換成自己的理解，才能消化。下面我們來舉個例子：比如，我們要實現人的吃飯功能（原諒我現在肚子 有點餓），
這是未使用依賴倒置的設計，
圖中，我們可以看到，人有乙個行為叫「吃飯」，而吃飯直接依賴公尺和麵這兩個物件。像這樣的設計，如果再加一種食物，比如土豆，不僅要增加土豆的類，還要修改人的「吃飯」行為。這將非常不利於系統的擴充套件。
而如果我們採用依賴倒置的設計，那麼設計會是這樣的：
人「吃飯」的行為不再直接依賴公尺飯和麵條這樣具體的低層模組，而是依賴於公尺飯、麵條這些具象的抽象結果——食物。如果這時候，來了土豆，玉公尺，只需要實現我們的抽象「食物」，而人的吃飯行為因為依賴於食物這個抽象，所以不再需要改動。
這就是採用依賴倒置設計的好處。
依賴倒置的**太多了，吾懶勁已上，諸君可自搜。
設計模式 依賴倒置
高層模組不應該依賴底層模組，兩者都應該依賴其抽象 抽象不應該依賴細節 細節應該依賴抽象。public inte ce idriver public class driver implements idriver public inte ce icar public class benz implem...
設計模式 依賴倒置原則
what high level modules should note depend upon low level modules.both should depend 高層模組不應該依賴底層模組，兩者都應該其抽象 抽象不應該依賴細節 細節應該依賴抽象 模組間的依賴通過抽象發生，實現類之間不發生直接...
設計模式 依賴倒置 DIP
高層次的模組不應該依賴 於 低層次的模組，兩者都應該依賴於 抽象介面。抽象的介面不應該依賴於具體的實現，而具體的實現依賴於抽象的介面 這個可能和我們常見的 熟能生巧 成為反比，平時我們設計了很多具體實現，才慢慢發現，其中的道，於是後來就抽象出來一種靈巧的方式，完成我們的工作 但是在快速，協作的開發環...