第1篇: 講述了如何創造"縫". "縫"(seam)是需要知道的概念.
第2篇, 避免在構建對象時寫出不易測試的代碼.
本文是第3篇, 講述依賴項和迪米特法則.
迪米特法則 (Law of Demeter)
還是使用建造汽車的例子. 生產汽車的時候需要輪胎, 組裝時需要什么型號的輪胎, 就請求該型號的輪胎, 然后相關人員會從庫房把該型號的輪胎送到產線用於組裝.
我相信很少有汽車廠會這樣做: 生產汽車時, 汽車組裝工拿着庫房的鑰匙, 自己去庫房從各種各樣的輪胎中找所需要的型號..
這就是違反迪米特法則的一個例子.
迪米特法則大概的意思是: "只訪問你自己創建的對象, 或者作為參數傳給你的對象. 不要通過其它對象間接的訪問對象"
用一句話歸納迪米特法則就是: "只與直系朋友交談, 不要和陌生人交談".
注意: 迪米特法則其實並不算嚴格的法則, 它只是一個非常有益的指導性原則.
存在的問題
用代碼形容上面的例子就是:
這違反了迪米特法則, 導致了以下問題:
- 造成了BenzCar和Warehouse以及MichelinTire之間的緊耦合, 而實際上BenzCar只需要MichelinTire.
- 測試時, 設置會很麻煩. 代碼里Warehouse是直系朋友, MichelinTire是陌生人. 我們需要為Warehouse和MichelinTire同時設置測試替身.
- 真正需要的依賴項沒有明確在構造函數里定義. 這里Warehouse相當於是一個容器, 測試時, 我們可能會不知道要為Warehouse里的哪個東西做測試替身.
危險信號
下列寫法可能意味着您的代碼違反了迪米特法則:
- 代碼里有這樣的調用: "warehouse.getTire.getMichelinTire", 有一連串的點".". 但是有時候這樣做是可以的, 例如流暢(fluent)形式的建造者模式就可以, 因為fluent接口通常會返回對象本身, 然后再去使用該對象.
- 依賴於容器. 例如把 IocContainer作為依賴注入使用.
- 依賴項的名稱為XxxContext, XxxContainer, XxxEnvironment, XxxManager, XxxServiceLocator.
- 測試時需要創建返回mocks的mock對象.
- 測試時的設置非常麻煩.
解決辦法
解決辦法就是遵從迪米特法則.
只注入我們直接需要的依賴項, 直接使用它們. 這樣就會保證依賴項很明確, 測試的時候一眼就能看出依賴於哪些對象.
代碼示例
例子一
下面這個違反了迪米特法則, 直接注入的是Warehouse, 而實際用到的卻是MichelinTire:
正確的做法是, 注入直接使用的依賴項:
例子二
下面的代碼也違反了迪米特法則, 它注入了一個容器類的對象:
這個ServiceLocator就相當於是一個容器. 這樣用的話, 寫測試的人可能根本無法知道需要使用容器里面的哪個對象.
你也許會說這樣做靈活(我以前也經常這樣做), 但是重構的時候, 這里很容易出錯, 因為根本看不出來真正依賴的是哪個對象.
正確的做法還是應該注入直接需要的依賴項:
Law of Demeter相關的內容就簡單介紹這些.