依賴倒轉原則

轉載 依賴倒轉原則

3.1 依賴倒置原則的定義

     依賴倒置原則（Dependence Inversion Principle，簡稱DIP）這個名字看着有點彆扭，“依賴”還“倒置”，這到底是什麼意思？依賴倒置原則的原始定義是：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。翻譯過來，包含三層含義：

• 高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；
• 抽象不應該依賴細節；
• 細節應該依賴抽象。

     高層模塊和低層模塊容易理解，每一個邏輯的實現都是由原子邏輯組成的，不可分割的原子邏輯就是低層模塊，原子邏輯的再組裝就是高層模塊。那什麼是抽象，什麼又是細節呢？在Java語言中，抽象就是指接口或抽象類，兩者都是不能直接被實例化的；細節就是實現類，實現接口或繼承抽象類而產生的類就是細節，其特點就是可以直接被實例化，也就是可以加上一個關鍵字new產生一個對象。依賴倒置原則在Java語言中的表現就是：

• 模塊間的依賴是通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過接口或抽象類產生的；
• 接口或抽象類不依賴於實現類；
• 實現類依賴接口或抽象類。

     更加精簡的定義就是“面向接口編程”——OOD（Object-Oriented Design，面向對象設計）的精髓之一。

3.2 言而無信，你太需要契約

     採用依賴倒置原則可以減少類間的耦合性，提高系統的穩定性，減少並行開發引起的風險，提高代碼的可讀性和可維護性。

     證明一個定理是否正確，有兩種常用的方法：一種是根據提出的論題，經過一番論證，推出和定理相同的結論，這是順推證法；還有一種是首先假設提出的命題是僞命題，然後推導出一個荒謬、與已知條件互斥的結論，這是反證法。我們今天就用反證法來證明依賴倒置原則是多麼的優秀和偉大！

     論題：依賴倒置原則可以減少類間的耦合性，提高系統的穩定性，減少並行開發引起的風險，提高代碼的可讀性和維護性。

     反論題：不使用依賴倒置原則也可以減少類間的耦合性，提高系統的穩定性，減少並行開發引起的風險，提高代碼的可讀性和維護性。

     我們通過一個例子來說明反論題是不成立的。現在的汽車越來越便宜了，也就頂多一個衛生間的價格就可以買到一輛不錯的汽車，有汽車就必然有人來駕駛了，司機駕駛奔馳車的類圖如圖3-1所示。

圖3-1 司機駕駛奔馳車類圖

     奔馳車可以提供一個方法run，代表車輛運行，實現過程如代碼清代3-1所示。

代碼清單3-1 司機源代碼

1 2 3 4 5 6 7 8 9 10 11

public class Driver {    //司機的主要職責就是駕駛汽車    public void drive(Benz benz){    benz.run();    }    }

     司機通過調用奔馳車的run方法開動奔馳車，其源代碼如代碼清單3-2所示。

代碼清單3-2 奔馳車源代碼

1 2 3 4 5 6 7 8 9 10 11

public class Benz {    //汽車肯定會跑    public void run(){    System.out.println("奔馳汽車開始運行...");    }    }

     有車，有司機，在Client場景類產生相應的對象，其源代碼如代碼清代3-3所示。

代碼清單3-3 場景類源代碼

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class Client {    public static void main(String[] args) {    Driver zhangSan = new Driver();    Benz benz = new Benz();    //張三開奔馳車    zhangSan.drive(benz);    }    }

     通過以上的代碼，完成了司機開動奔馳車的場景，到目前爲止，這個司機開奔馳車的項目沒有任何問題。我們常說“危難時刻見真情”，我們把這句話移植到技術上就成了“變更才顯真功夫”，業務需求變更永無休止，技術前進就永無止境，在發生變更時才能發覺我們的設計或程序是否是鬆耦合。我們在一段貌似磐石的程序上加上一塊小石頭：張三司機不僅要開奔馳車，還要開寶馬車，又該怎麼實現呢？麻煩出來了，那好，我們走一步是一步，我們先把寶馬車產生出來，實現過程如代碼清單3-4所示。

代碼清單3-4 寶馬車源代碼

1 2 3 4 5 6 7 8 9 10 11

public class BMW {    //寶馬車當然也可以開動了    public void run(){    System.out.println("寶馬汽車開始運行...");    }    }

     寶馬車也產生了，但是我們卻沒有辦法讓張三開動起來，爲什麼？張三沒有開動寶馬車的方法呀！一個拿有C照的司機竟然只能開奔馳車而不能開寶馬車，這也太不合理了！在現實世界都不允許存在這種情況，何況程序還是對現實世界的抽象，我們的設計出現了問題：司機類和奔馳車類之間是一個緊耦合的關係，其導致的結果就是系統的可維護性大大降低，可讀性降低，兩個相似的類需要閱讀兩個文件，你樂意嗎？還有穩定性，什麼是穩定性？固化的、健壯的纔是穩定的，這裏只是增加了一個車類就需要修改司機類，這不是穩定性，這是易變性。被依賴者的變更竟然讓依賴者來承擔修改的成本，這樣的依賴關係誰肯承擔！證明到這裏，我們已經知道僞命題已經部分不成立了。

     注意 設計是否具備穩定性，只要適當的“鬆鬆土”，觀察“設計的藍圖”是否還可以茁壯的成長就可以得出結論，穩定性較高的設計，在周圍環境頻繁變化的時候，依然可以做到“我自巋然不動”。

     我們繼續證明，“減少並行開發引起的風險”，什麼是並行開發的風險？並行開發最大的風險就是風險擴散，本來只是一段程序的錯誤或異常，逐步波及一個功能，一個模塊，甚至到最後毀壞了整個項目，爲什麼並行開發就有這個風險呢？一個團隊，20人開發，各人負責不同的功能模塊，甲負責汽車類的建造，乙負責司機類的建造，在甲沒有完成的情況下，乙是不能完全地編寫代碼的，缺少汽車類，編譯器根本就不會讓你通過！在缺少Benz類的情況下，Driver類能編譯嗎？更不要說是單元測試了！在這種不使用依賴倒置原則的環境中，所有的開發工作都是“單線程”的，甲做完，乙再做，然後是丙繼續…，這在90年代“個人英雄主義”編程模式中還是比較適用的，一個人完成所有的代碼工作，但在現在的大中型項目中已經是完全不能勝任了，一個項目是一個團隊的協作結果，一個“英雄”再牛X也不可能瞭解所有的業務和所有的技術，要協作就要並行開發，要並行開發就要解決模塊之間的項目依賴關係，那然後呢？依賴倒置原則就隆重出場了！

     根據以上證明，如果不使用依賴倒置原則就會加重類間的耦合性，降低系統的穩定性，增加並行開發引起的風險，降低代碼的可讀性和維護性。承接上面的例子，引入依賴倒置原則後的類圖如圖3-2所示。

圖3-2 引入依賴倒置原則後的類圖

     建立兩個接口：IDriver和ICar，分別定義了司機和汽車的各個職能，司機就是駕駛汽車，必須實現drive()方法，其實現過程如代碼清單3-5所示。

代碼清單3-5 司機接口

1 2 3 4 5 6 7

public interface IDriver {    //是司機就應該會駕駛汽車    public void drive(ICar car);    }

     接口只是一個抽象化的概念，是對一類事物的最抽象描述，具體的實現代碼由相應的實現類來完成，Driver實現類如代碼清單3-6所示。

代碼清單3-6 司機類的實現

1 2 3 4 5 6 7 8 9 10 11

public class Driver implements IDriver{    //司機的主要職責就是駕駛汽車    public void drive(ICar car){    car.run();    }    }

     在IDriver中，通過傳入ICar接口實現了抽象之間的依賴關係，Driver實現類也傳入了ICar接口，至於到底是哪個型號的Car需要在高層模塊中聲明。

     ICar及其兩個實現類的實現過程如代碼清單3-7所示。

代碼清單3-7 汽車接口及兩個實現類

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

public interface ICar {    //是汽車就應該能跑    public void run();    }    public class Benz implements ICar{    //汽車肯定會跑    public void run(){    System.out.println("奔馳汽車開始運行...");    }    }    public class BMW implements ICar{    //寶馬車當然也可以開動了    public void run(){    System.out.println("寶馬汽車開始運行...");    }    }

     在業務場景中，我們貫徹“抽象不應該依賴細節”，也就是我們認爲抽象（ICar接口）不依賴BMW和Benz兩個實現類（細節），因此我們在高層次的模塊中應用都是抽象，Client的實現過程如代碼清單3-8所示。

代碼清單3-8 業務場景

public class Client {

public static void main(String[] args) {

IDriver zhangSan = new Driver();

ICar benz = new Benz();

//張三開奔馳車

zhangSan.drive(benz);

}

}

     Client屬於高層業務邏輯，它對低層模塊的依賴都建立在抽象上，zhangSan的顯示類型是IDriver，benz的顯示類型是ICar，也許你要問，在這個高層模塊中也調用到了低層模塊，比如new Driver()和new Benz()等，如何解釋？確實如此，zhangSan的顯示類型是IDriver，是一個接口，是抽象的，非實體化的，在其後的所有操作中，zhangSan都是以IDriver類型進行操作，屏蔽了細節對抽象的影響。當然，張三如果要開寶馬車，也很容易，我們只要修改業務場景類就可以，實現過程如代碼清單3-9所示。

代碼清單3-9 張三駕駛寶馬車的實現過程

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class Client {    public static void main(String[] args) {    IDriver zhangSan = new Driver();    ICar bmw = new BMW();    //張三開奔馳車    zhangSan.drive(bmw);    }    }

     在新增加低層模塊時，只修改了業務場景類，也就是高層模塊，對其他低層模塊如Driver類不需要做任何修改，業務就可以運行，把“變更”引起的風險擴散降低到最小。

     注意 在Java中，只要定義變量就必然要有類型，一個變量可以有兩個類型：顯示類型和真實類型，顯示類型是在定義的時候賦予的類型，真實類型是對象的類型，如zhangSan的顯示類型是IDriver，真實類型是Driver。

     我們再來思考依賴倒轉對並行開發的影響。兩個類之間有依賴關係，只要制定出兩者之間的接口（或抽象類）就可以獨立開發了，而且項目之間的單元測試也可以獨立的運行，而TDD（Test-Driven Development，測試驅動開發）開發模式就是依賴倒置原則的最高級應用。我們繼續回顧上面司機駕駛汽車的例子，甲程序員負責IDriver的開發，乙程序員負責ICar的開發，兩個開發人員只要制定好了接口就可以獨立地開發了，甲開發進度比較快，完成了IDriver以及相關的實現類Driver的開發工作，而乙程序員滯後開發，那甲是否可以進行單元測試（Unit Test）呢？答案是可以，我們引入一個JMock工具，其最基本的功能是根據抽象虛擬一個對象進行測試，測試類如代碼清單3-10所示。

代碼清單3-10 測試類

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

public class DriverTest extends TestCase{    Mockery context = new JUnit4Mockery();    @Test    public void testDriver() {    //根據接口虛擬一個對象    final ICar car = context.mock(ICar.class);    IDriver driver = new Driver();    //內部類    context.checking(new Expectations(){{    oneOf (car).run();    }});    driver.drive(car);    }    }

     注意粗體部分，我們只需要一個ICar的接口，就可以對Driver類進行單元測試，從這一點來看，兩個相互依賴的對象可以分別進行開發，孤立的單元測試，進而保證並行開發的效率和質量，TDD開發的精髓不就在這裏嗎？測試驅動開發，先寫好單元測試類，然後再寫實現類，這對代碼的質量有非常大的提高，特別適合研發類項目或在項目成員整體水平比較低的情況下采用。

     抽象是對實現的約束，對依賴者而言，也是一種契約，不僅僅約束自己，還同時約束自己與外部的關係，其目的是保證所有的細節不逃脫契約的範疇，確保約束雙方按照既定的契約(抽象)共同發展，只要抽象這根基線在，細節就逃脫不了這個圈圈，始終讓你的對象做到“言而有信”“言出必行”

3.3 依賴的三種寫法

     依賴是可以傳遞的，A對象依賴B對象，B又依賴C，C又依賴D…，生生不息，依賴不止，記住一點：只要做到抽象依賴，即使是多層的依賴傳遞也無所畏懼！

     對象的依賴關係有三種方式來傳遞，如下所示。

• 構造函數傳遞依賴對象

     在類中通過構造函數聲明依賴對象，按照依賴注入的說法這種方式叫做構造函數注入，按照這種方式的注入，IDriver和Driver的程序修改後如代碼清單3-11所示。

代碼清單3-11 構造函數傳遞依賴對象

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

public interface IDriver {    //是司機就應該會駕駛汽車    public void drive();    }    public class Driver implements IDriver{    private ICar car;    //構造函數注入    public Driver(ICar _car){    this.car = _car;    }    //司機的主要職責就是駕駛汽車    public void drive(){    this.car.run();    }    }

• Setter方法傳遞依賴對象

     在抽象中設置setter方法聲明依賴關係，依照依賴注入的說法就是setter依賴注入，按照這種方式的注入，IDriver和Driver的程序修改後如代碼清單3-12所示。

代碼清單3-12 Setter依賴注入

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

public interface IDriver {    //車輛型號    public void setCar(ICar car);    //是司機就應該會駕駛汽車    public void drive();    }    public class Driver implements IDriver{    private ICar car;    public void setCar(ICar car){    this.car = car;    }    //司機的主要職責就是駕駛汽車    public void drive(){    this.car.run();    }    }

• 接口聲明依賴對象

     在接口的方法中聲明依賴對象，3.2章節的例子就是採用了接口聲明依賴的方式，，該方法也叫做接口注入。

3.4 最佳實踐

     依賴倒轉原則的本質就是通過抽象（接口或抽象類）使各個類或模塊的實現彼此獨立，不互相影響，實現模塊間的鬆耦合，我們怎麼在項目中使用這個規則呢？只要遵循以下的幾個規則就可以：

• 每個類儘量都有接口或抽象類，或者抽象類和接口兩者都具備。

     這是依賴倒置的基本要求，接口和抽象類都是屬於抽象的，有了抽象纔可能依賴倒置。

• 變量的顯示類型儘量是接口或者是抽象類。

     很多書上說變量的類型一定要是接口或者是抽象類，這個有點絕對化了，比如一個工具類，xxxUtils一般是不需要接口或是抽象類的。還有，如果你要使用類的clone方法，就必須使用實現類，這個是JDK提供一個規範。

• 任何類都不應該從具體類派生。

     如果一個項目處於開發狀態，確實不應該有從具體類派生出的子類的情況，但這也不是絕對的，因爲人都是會犯錯誤的，有時設計缺陷是在所難免的，因此只要不超過兩層的繼承都是可以忍受的。特別是做項目維護的同志，基本上可以不考慮這個規則，爲什麼？維護工作基本上都是做擴展開發，修復行爲，通過一個繼承關係，覆寫一個方法就可以修正一個很大的Bug，何必再要去繼承最高的基類呢？

• 儘量不要覆寫基類的方法。

     如果基類是一個抽象類，而且這個方法已經實現了，子類儘量不要覆寫。類間依賴的是抽象，覆寫了抽象方法，對依賴的穩定性會產生一定的影響。

• 結合里氏替換原則使用

     在上一個章節中我們講解了里氏替換原則，父類出現的地方子類就能出現，再結合本章節的講解，我們可以得出這樣一個通俗的規則： 接口負責定義public屬性和方法，並且聲明與其他對象的依賴關係，抽象類負責公共構造部分的實現，實現類準確的實現業務邏輯，同時在適當的時候對父類進行細化。

     講了這麼多，估計大家對“倒置”這個詞還是有點不理解，那到底什麼是“倒置”呢？我們先說“正置”是什麼意思，依賴正置就是類間的依賴是實實在在的實現類間的依賴，也就是面向實現編程，這也是正常人的思維方式，我要開奔馳車就依賴奔馳車，我要使用筆記本電腦就直接依賴筆記本電腦，而編寫程序需要的是對現實世界的事物進行抽象，抽象的結果就是有了抽象類和接口，然後我們根據系統設計的需要產生了抽象間的依賴，代替了人們傳統思維中的事物間的依賴，“倒置”就是從這裏產生的。

     依賴倒置原則的優點在小型項目中很難體現出來，例如小於10個人月的項目，使用簡單的SSH架構，基本上不費太大力氣就可以完成，是否採用依賴倒置原則影響不大。但是，在一個大中型項目中，採用依賴倒置原則可以帶來非常多的優點，特別是規避一些非技術因素引起的問題。項目越大，需求變化的概率也越大，通過採用依賴倒置原則設計的接口或抽象類對實現類進行約束，可以減少需求變化引起的工作量劇增的情況。人員的變動在大中型項目中也是時常存在的，如果設計優良、代碼結構清晰，人員變化對項目的影響基本爲零。大中型項目的維護週期一般都很長，採用依賴倒置原則可以讓維護人員輕鬆地擴展和維護。

     依賴倒置原則是六個設計原則中最難以實現的原則，它是實現開閉原則的重要途徑，依賴倒置原則沒有實現，就別想實現對擴展開放，對修改關閉。在項目中，大家只要記住是“面向接口編程”就基本上抓住了依賴倒轉原則的核心。

     講了這麼多依賴倒置原則的優點，我們也來打擊一下大家，在現實世界中確實存在着必須依賴細節的事物，比如法律，就必須依賴細節的定義。 “殺人償命”在中國的法律中古今有之，那這裏的殺人就是一個抽象的含義，怎麼殺，殺什麼人，爲什麼殺人，都沒有定義，只要是殺人就統統得償命，那這就是有問題了，好人殺了壞人，還要陪上自己的一條性命，這是不公正的，從這一點看，我們在實際的項目中使用依賴倒置原則時需要審時度勢，不要抓住一個原則不放，每一個原則的優點都是有限度的，並不是放之四海而皆準的真理，所以別爲了遵循一個原則而放棄了一個項目的終極目標：投產上線和盈利。作爲一個項目經理或架構師，應該懂得技術只是實現目的的工具，惹惱了頂頭上司，設計做得再漂亮，代碼寫得再完美，項目做得再符合標準，一旦項目虧本，產品投入大於產出，那整體就是扯淡！你自己也別想混得更好！