.NET Core TDD 前传: 编写易于测试的代码 -- 依赖项
第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相關的內容就簡單介紹這些.
原文地址：https://www.cnblogs.com/cgzl/p/9389176.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的.NET Core TDD 前传: 编写易于测试的代码 -- 依赖项的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Go vs .NET Core 2.1
- 下一篇： .Net Core中的日志组件(Logg