3.2 言而無信，你太需要契約 采用依賴倒置原則可以減少類間的耦合性，提高系統的穩定性，降低并行開發引起的風險，提高代碼的可讀性和可維護性。 證明一個定理是否正確，有兩種常用的方法：一種是根據提出的論題，經過一番論證，推出和定理相同的結論，這是順推證法；還有一種是首先假設提出的命題是偽命題，然后推導出一個荒謬、與已知條件互斥的結論，這是反證法。我們今天就用反證法來證明依賴倒置原則是多么優秀和偉大！ 論題：依賴倒置原則可以減少類間的耦合性，提高系統的穩定性，降低并行開發引起的風險，提高代碼的可讀性和可維護性。 反論題：不使用依賴倒置原則也可以減少類間的耦合性，提高系統的穩定性，降低并行開發引起的風險，提高代碼的可讀性和可維護性。 我們通過一個例子來說明反論題是不成立的。現在的汽車越來越便宜了，一個衛生間的造價就可以買到一輛不錯的汽車，有汽車就必然有人來駕駛，司機駕駛奔馳車的類圖如圖3-1所示。  圖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所示。  圖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類不需要做任何修改，業務就可以運行，把“變更”引起的風險擴散降到最低。 注意　在Java中，只要定義變量就必然要有類型，一個變量可以有兩種類型：表面類型和實際類型，表面類型是在定義的時候賦予的類型，實際類型是對象的類型，如zhangSan的表面類型是IDriver，實際類型是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開發的精髓不就在這里嗎？測試驅動開發，先寫好單元測試類，然后再寫實現類，這對提高代碼的質量有非常大的幫助，特別適合研發類項目或在項目成員整體水平比較低的情況下采用。 抽象是對實現的約束，對依賴者而言，也是一種契約，不僅僅約束自己，還同時約束自己與外部的關系，其目的是保證所有的細節不脫離契約的范疇，確保約束雙方按照既定的契約（抽象）共同發展，只要抽象這根基線在，細節就脫離不了這個圈圈，始終讓你的對象做到“言必信，行必果”。