DIP依賴倒置原則

1、定義

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

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

2、層次化

　　1.簡單介紹

　　結構良好的面向對象架構都具備清晰的層次定義，每一個層次經過一個定義良好的、受控的接口向外提供了一組內聚的服務。

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

　　　　

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

　　下圖則展現了一個更爲合適的模型。 每一個較高層次都爲它所須要的服務聲明一個抽象接口。較低的層次實現了這些抽象接口。每一個高層類都經過該抽象接口使用下一層，這樣高層就不依賴於低層。低層反而依賴於在高層中聲明的抽象服務接口。這解除了Policy層、Mechanism層和Utility層的兩兩依賴關係。

　　　　

　　2.倒置的接口全部權

　　這裏的倒置不單單是依賴關係的倒置，它也是接口全部權的倒置。

　　可是當應用DIP時，咱們發現每每是客戶擁有抽象接口，而它們的服務者則從這些抽象接口派生。

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

　　低層模塊實現了在高層模塊中聲明並被高層模塊調用的接口。

　　Hollywood原則解釋：

//不該用IOC
class A
{
    B b = new B(); 
} 
//應用IOC 
class A 
{
    B b = null; // 你不須要本身找B,當你須要的時候，B會自動替你初始化。
    public A(B b)
    {
        this.b=b;
    }     
}    

　　經過這種致使的接口全部權，對於Mechanism層或者Utility層的任務改動都不會再影響到Policy層。並且，Policy層能夠定義符合policyServiceInstance的任何上下文重用。經過倒置這些依賴關係，咱們建立了一個更靈活、更持久、更易改變的結構。

　　3.依賴於抽象

　　依賴於抽象建議咱們不該該依賴於具體類--也就是說，程序中全部的依賴關係都應該終止於抽象類或者接口。

• 任何變量都不該該持有一個指向具體類的引用
• 任何類都不該該從具體類派生
• 任何方法都不該該重寫它的任何基類中的已實現了的方法 有時必須建立具體類的實例，而建立的模塊將會依賴它們，若是一個具體的類不太會改變，而且也不會建立其餘相似的派生類，那麼依賴於它並不會形成損害。

3、結論

　　事實上，這種依賴關係的致使正是好的面向對象設計的標誌所在。使用何種語言來編寫程序是可有可無的。若是程序的依賴關係是倒置的，他就是面向對象的設計。若是程序的依賴關係不是倒置的，他就是過程化設計。