DIP依賴倒置原則

1.高層模組不應該依賴低層模組，二者都應該依賴抽象

2.抽象不應該依賴於細節。細節應該依賴於抽象

1.簡單介紹

結構良好的物件導向架構都具有清晰的層次定義，每個層次通過乙個定義良好的、受控的介面向外提供了一組內聚的服務。

對於這個陳述的簡單理解可能會致使設計者設計出類似下圖的結構。

圖中，高層的policy層使用了低層的mechanism層，而mechanism層又使用了更細節的utility層。這樣，policy層對下面的utility層的改動都是敏感的。這種依賴關係是傳遞的。這是非常糟糕的。

下圖則展示了乙個更為合適的模型。每個較高層次都為它所需要的服務宣告乙個抽象介面。較低的層次實現了這些抽象介面。每個高層類都通過該抽象介面使用下一層，這樣高層就不依賴於低層。低層反而依賴於在高層中宣告的抽象服務介面。這解除了policy層、mechanism層和utility層的兩兩依賴關係。

2.倒置的介面所有權

這裡的倒置不僅僅是依賴關係的倒置，它也是介面所有權的倒置。

但是當應用dip時，我們發現往往是客戶擁有抽象介面，而它們的服務者則從這些抽象介面派生。

這就是著名的hollywood(好萊塢)原則:"don't call us,we'll call you.(不要找我們，我們會去找你)"。

低層模組實現了在高層模組中宣告並被高層模組呼叫的介面。

hollywood原則解釋：

不應用ioc

classa

//應用ioc

class

}

通過這種導致的介面所有權，對於mechanism層或者utility層的任務改動都不會再影響到policy層。而且，policy層可以定義符合policyserviceinstance的任何上下文重用。通過倒置這些依賴關係，我們建立了乙個更靈活、更持久、更易改變的結構。

3.依賴於抽象

依賴於抽象建議我們不應該依賴於具體類--也就是說，程式中所有的依賴關係都應該終止於抽象類或者介面。

事實上，這種依賴關係的導致正是好的物件導向設計的標誌所在。使用何種語言來編寫程式是無關緊要的。如果程式的依賴關係是倒置的，他就是物件導向的設計。如果程式的依賴關係不是倒置的，他就是過程化設計。