"要依賴於抽象，不要依賴於具體。」
「要針對介面程式設計，不要針對實現程式設計。」
陳述：
分析：
層次化：
——booch
對上述論述可能存在兩種不同的理解：
1)依賴關係倒置
下層的實現，依賴於上層的介面
2)介面所有權倒置
客戶擁有介面，而服務者則從這些介面派生
我們可以分兩種模式來定義：
1、依賴不倒置的開發：自頂向下首先設計整個軟體的分解結構，然後首先實現下層的功能，再實現上層的功能，並使上層呼叫下層函式。
2、依賴倒置的開發：首先設計上層需要呼叫的介面，並實現上層，然後低層類從上層介面派生，實現低層。在這種情況下，
介面屬於上層。
例項
我們來看一下button與lamp：
button（開關）感知外界的變化。
當接受到poll（輪詢）訊息時，判斷其是否被「按下」。這個按下是抽象的（不關心通過什麼樣的機制去感知）：
lamp（燈）根據指示，收到turn on訊息顯示某種燈光，收到turn off訊息關閉燈光
應該如何設計程式來用button控制lamp呢？
初步設計
button物件直接依賴lamp物件，從而：
[cpp]view plain
copy
print?
class button
}；
class button
}；
改進思路
依賴於抽象
什麼是高層策略？就是應用背後的抽象----背後的抽象是檢測使用者的開/關指令：
改進後的設計：
button依賴於抽象的介面buttonserver（向該介面發訊息）。buttonserver提供一些抽象的方法，button類通過這些介面可以開啟或關掉一些東西。
lamp也依賴於buttonserver介面（從此介面派生），提供具體的實現。
如下圖所示：
部分**：
[cpp]view plain
copy
print?
#include "buttonserver.h"
class button;
void button::poll( )
#include "buttonserver.h"
class button;
void button::poll( )
copy
print?
class buttonserver;
class lamp:public buttonserver;
void lamp::turnon()
void lamp::turnoff()
class buttonserver;
class lamp:public buttonserver;
void lamp::turnon()
void lamp::turnoff()
質疑：
這樣的設計是不是強加了這樣乙個約束——所有需要被button控制的物件一定要實現buttonserver類。
如果我的裝置還希望能夠被另乙個物件控制，比如switch控制，怎麼辦？
這種設計是不是將button對lamp的依賴轉嫁成了lamp對button的依賴呢？（畢竟lamp只能被一種button控制也是不好的）
抗辯：
上述質疑不成立。button依賴於buttonserver介面，但是介面並不依賴於button，也就是說任何知道如何操作buttonserver介面的物件都可以操作lamp。
也許需要改進的僅僅是buttonserver這樣乙個有些「誤導性」的名字，我們可以將這個名字該得更加抽象一些，例如：switchabledevice
總結
使用傳統過程化設計所創造出來的依賴關係結構，策略是依賴於細節的。----策略受細節改變影響
物件導向程式設計倒置了依賴關係結構，使細節和策略都依賴於抽象，成為物件導向設計的標誌。
依賴倒置原則是實現物件導向技術的基本低層機制，有利於復用和維護。
依賴倒置原則假定具體類都是會變化的，避免對具體類的直接引用，可能會導致大量的類。功能強大，最不容易實現。
相應設計模式：
factory method
prototype
iterator
參考資源：
《設計模式：可復用物件導向軟體的基礎》，erich gamma richard helm ralph johnson john vlissides著作，李英軍 馬曉星 蔡敏 劉建中譯，機械工業出版社，2005.6
《敏捷軟體開發：原則、模式與實踐》，robert c. martin著，鄧輝譯，清華大學出版社，2003.9
《設計模式解析》，alan shalloway等著（徐言聲譯），人民郵電出版社，2006.10
軟體設計原則 依賴倒置原則
依賴倒置原則 dependence inversion principle,dip 高層模組不應該依賴底層模組,二者都應該依賴其抽象.抽象不應該依賴細節,細節應該依賴抽象.new 乙個小明 public class xiaoming public void studyartscourse 呼叫一下 ...
設計模式原則 依賴倒置原則（DIP）
定義 高層模組不應該依賴低層模組，二者都應該依賴其抽象 抽象不應該依賴細節 細節應該依賴抽象。問題由來 類a直接依賴類b，假如要將類a改為依賴類c，則必須通過修改類a的 來達成。這種場景下，類a一般是高層模組，負責複雜的業務邏輯 類b和類c是低層模組，負責基本的原子操作 假如修改類a，會給程式帶來不...
依賴倒置原則 DIP
一 dip簡介 dip dependency inversion principle 1 高層模組不應該依賴於低層模組,二者都應該依賴於抽象。2 抽象不應該依賴於細節,細節應該依賴於抽象。高層模組包含了乙個應該程式中的重要的策略選擇和業務模型，正是這些高層模組才使得其所有的應用程式區別於其他，如果高...