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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

代碼清單3-5 司機接口

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

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

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

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

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

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

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

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 張三駕駛寶馬車的實現過程

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

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

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

代碼清單3-10 測試類

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開發的精髓不就在這里嗎？測試驅動開發，先寫好單元測試類，然后再寫實現類，這對提高代碼的質量有非常大的幫助，特別適合研發類項目或在項目成員整體水平比較低的情況下采用。

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