定義：高層模塊不應該依賴低層模塊吼和，二者都應該依賴其抽象擎值；抽象不應該依賴細節(jié)；細節(jié)應該依賴抽象鲫忍。問題由來：類A直接依賴類B膏燕，假如要將類A改為依賴類C，則必須通過修改類A的代碼來達成悟民。這種場景下坝辫，類A一般是高層模塊，負責復雜的業(yè)務邏輯射亏；類B和類C是低層模塊近忙，負責基本的原子操作竭业；假如修改類A，會給程序帶來不必要的風險及舍。
解決方案：將類A修改為依賴接口I未辆，類B和類C各自實現(xiàn)接口I，類A通過接口I間接與類B或者類C發(fā)生聯(lián)系锯玛，則會大大降低修改類A的幾率咐柜。
依賴倒置原則基于這樣一個事實：相對于細節(jié)的多變性，抽象的東西要穩(wěn)定的多攘残。以抽象為基礎搭建起來的架構比以細節(jié)為基礎搭建起來的架構要穩(wěn)定的多拙友。在java中，抽象指的是接口或者抽象類歼郭，細節(jié)就是具體的實現(xiàn)類遗契，使用接口或者抽象類的目的是制定好規(guī)范和契約，而不去涉及任何具體的操作病曾，把展現(xiàn)細節(jié)的任務交給他們的實現(xiàn)類去完成牍蜂。
依賴倒置原則的核心思想是面向接口編程，我們依舊用一個例子來說明面向接口編程比相對于面向實現(xiàn)編程好在什么地方泰涂。場景是這樣的捷兰，母親給孩子講故事，只要給她一本書负敏，她就可以照著書給孩子講故事了贡茅。代碼如下：
運行結果：
運行良好，假如有一天其做，需求變成這樣：不是給書而是給一份報紙顶考，讓這位母親講一下報紙上的故事，報紙的代碼如下：
這位母親卻辦不到妖泄，因為她居然不會讀報紙上的故事驹沿，這太荒唐了，只是將書換成報紙蹈胡，居然必須要修改Mother才能讀渊季。假如以后需求換成雜志呢？換成網頁呢罚渐？還要不斷地修改Mother却汉，這顯然不是好的設計。原因就是Mother與Book之間的耦合性太高了荷并，必須降低他們之間的耦合度才行合砂。
我們引入一個抽象的接口IReader。讀物源织，只要是帶字的都屬于讀物：
Mother類與接口IReader發(fā)生依賴關系翩伪，而Book和Newspaper都屬于讀物的范疇微猖，他們各自都去實現(xiàn)IReader接口，這樣就符合依賴倒置原則了缘屹，代碼修改為：
運行結果：
這樣修改后凛剥，無論以后怎樣擴展Client類，都不需要再修改Mother類了轻姿。這只是一個簡單的例子当悔，實際情況中，代表高層模塊的Mother類將負責完成主要的業(yè)務邏輯踢代，一旦需要對它進行修改，引入錯誤的風險極大嗅骄。所以遵循依賴倒置原則可以降低類之間的耦合性胳挎，提高系統(tǒng)的穩(wěn)定性，降低修改程序造成的風險溺森。
采用依賴倒置原則給多人并行開發(fā)帶來了極大的便利慕爬，比如上例中，原本Mother類與Book類直接耦合時屏积，Mother類必須等Book類編碼完成后才可以進行編碼医窿，因為Mother類依賴于Book類。修改后的程序則可以同時開工炊林，互不影響姥卢，因為Mother與Book類一點關系也沒有。參與協(xié)作開發(fā)的人越多渣聚、項目越龐大独榴，采用依賴導致原則的意義就越重大。現(xiàn)在很流行的TDD開發(fā)模式就是依賴倒置原則最成功的應用奕枝。
傳遞依賴關系有三種方式棺榔，以上的例子中使用的方法是接口傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞隘道，相信用過Spring框架的症歇，對依賴的傳遞方式一定不會陌生。在實際編程中谭梗，我們一般需要做到如下3點：
低層模塊盡量都要有抽象類或接口忘晤，或者兩者都有。
變量的聲明類型盡量是抽象類或接口激捏。
使用繼承時遵循里氏替換原則德频。
依賴倒置原則的核心就是要我們面向接口編程，理解了面向接口編程缩幸，也就理解了依賴倒置壹置。
