第1篇: 講述了如何創(chuàng)造"縫".? "縫"(seam)是需要知道的概念.

第2篇,?避免在構(gòu)建對象時寫出不易測試的代碼.

本文是第3篇, 講述依賴項和迪米特法則.

?

迪米特法則 (Law of Demeter)

還是使用建造汽車的例子. 生產(chǎn)汽車的時候需要輪胎, 組裝時需要什么型號的輪胎, 就請求該型號的輪胎, 然后相關(guān)人員會從庫房把該型號的輪胎送到產(chǎn)線用于組裝.?

我相信很少有汽車廠會這樣做: 生產(chǎn)汽車時, 汽車組裝工拿著庫房的鑰匙, 自己去庫房從各種各樣的輪胎中找所需要的型號..

這就是違反迪米特法則的一個例子.

?

迪米特法則大概的意思是: "只訪問你自己創(chuàng)建的對象, 或者作為參數(shù)傳給你的對象. 不要通過其它對象間接的訪問對象"

用一句話歸納迪米特法則就是: "只與直系朋友交談, 不要和陌生人交談".

?

注意: 迪米特法則其實并不算嚴格的法則, 它只是一個非常有益的指導性原則.?

?

存在的問題

用代碼形容上面的例子就是:?

這違反了迪米特法則, 導致了以下問題:

• 造成了BenzCar和Warehouse以及MichelinTire之間的緊耦合, 而實際上BenzCar只需要MichelinTire.

• 測試時,?設置會很麻煩. 代碼里Warehouse是直系朋友, MichelinTire是陌生人. 我們需要為Warehouse和MichelinTire同時設置測試替身.

• 真正需要的依賴項沒有明確在構(gòu)造函數(shù)里定義. 這里Warehouse相當于是一個容器, 測試時, 我們可能會不知道要為Warehouse里的哪個東西做測試替身.

?

危險信號

下列寫法可能意味著您的代碼違反了迪米特法則:

• 代碼里有這樣的調(diào)用: "warehouse.getTire.getMichelinTire", 有一連串的點".". 但是有時候這樣做是可以的, 例如流暢(fluent)形式的建造者模式就可以, 因為fluent接口通常會返回對象本身, 然后再去使用該對象.

• 依賴于容器. 例如把 IocContainer作為依賴注入使用.?

• 依賴項的名稱為XxxContext, XxxContainer, XxxEnvironment, XxxManager, XxxServiceLocator.

• 測試時需要創(chuàng)建返回mocks的mock對象.

• 測試時的設置非常麻煩.

?

解決辦法

解決辦法就是遵從迪米特法則.

只注入我們直接需要的依賴項, 直接使用它們. 這樣就會保證依賴項很明確, 測試的時候一眼就能看出依賴于哪些對象.

代碼示例

例子一

下面這個違反了迪米特法則, 直接注入的是Warehouse, 而實際用到的卻是MichelinTire:

?

正確的做法是, 注入直接使用的依賴項:

?

例子二

下面的代碼也違反了迪米特法則, 它注入了一個容器類的對象:

這個ServiceLocator就相當于是一個容器. 這樣用的話, 寫測試的人可能根本無法知道需要使用容器里面的哪個對象.

你也許會說這樣做靈活(我以前也經(jīng)常這樣做), 但是重構(gòu)的時候, 這里很容易出錯, 因為根本看不出來真正依賴的是哪個對象.

?

正確的做法還是應該注入直接需要的依賴項:

?

Law of Demeter相關(guān)的內(nèi)容就簡單介紹這些.

原文地址：https://www.cnblogs.com/cgzl/p/9389176.html

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的.NET Core TDD 前传: 编写易于测试的代码 -- 依赖项的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。