.NET Core TDD 前傳: 編寫易於測試的代碼 -- 單一職責

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

第2篇, 避免在構建對象時寫出不易測試的代碼.

第3篇, 依賴項和迪米特法則.

第4篇, 全局狀態引發的問題.

本文是第5篇, 也是最後一篇, 介紹的是單一職責

 

類作了太多的工做

例子, 某軟件公司, 原有項目開發, 測試, 售前, 售後, 財務等員工. 後來因爲公司沒錢, 裁掉了測試, 讓開發兼職; 過了段時間, 又裁掉了需求和售後, 仍是由你這個開發來兼職; 再過了段時間, 又裁掉了財務和售前, 仍是由你來兼職.

某天上班以後, 你剛想寫代碼, 就接到了客戶來電, 說鍵盤很差用, 讓你去給調試一下. 花了1個小時從客戶那裏調試回來又剛想寫點代碼, 某客戶說發票沒給, 你又去快遞發票. 回來以後又想寫代碼, 又有客戶來電話諮詢你公司的XXX管理系統, 通過半個小時的講解, 客戶沒興趣. 這時已經到了中午, 你卻發現你的本職工做一點都作.

在現實世界中, 給某個員工賦與不少衝突的角色或職責是很不明智的.

在軟件開發裏也是這樣的, 在爲一個類賦予太多的職責會引出不少維護和測試的問題.

單一職責

單一職責是面向對象軟件設計的準則之一, 它說的是: "一個類只能由於一個緣由去改變".

這就是說咱們應該增長 由於相同緣由而作出改變的東西 的內聚性, 而下降 因爲不一樣緣由而作出改變的東西 的耦合性.

這句話一般被描述爲: "一個類或一個方法只應該作一件事情, 而且要把它作好".

 

若是一個類有了太多的職責, 那麼職責間的交互就會埋藏於類裏, 這樣作就很難一次修改一個職責. 對於測試來講, 這些交互之間也沒有明顯的"縫隙".

依賴項的構建工做並非目標類自己的職責, 這項工做應該和類自己的職責分開. 因此咱們會使用依賴注入配置好的對象. 咱們應該對類進行抽取, 讓其成爲單一職責的類.

 

引發的問題

若是一個類有多個職責, 那麼在測試上它會有如下問題:

• 若是一個類/方法有太多的功能, 那麼針對它的測試就會特別多, 很容易讓人難於理解也很難維護.
• 測試的設置也會更加的麻煩. 
• 因爲有多個緣由去修改該類, 那麼它的測試類/方法就會修改的更加頻繁.

 

危險信號

什麼樣的類/方法會違反單一職責呢?

• 若是你在描述該類功能的時候用到了"和", "或", "還", "而且"等詞.
• 類或者方法的代碼不少.
• 注入了太多的依賴項.
• 一個類改變的太頻繁了也可能意味着這個類的職責可能不止一個.

 

解決方案

若是一個類有不少職責, 那麼能夠這樣作:

• 識別出類裏面各個獨立的職責.
• 給每一個職責貼上標籤.
• 解耦, 把其它功能抽取到單獨的類, 最後保證每一個類都是單一職責.

 

例子

舉一個很簡單的典型例子:

 

這個類, 有4個依賴項, 不算特別多, 可是也很多. 它的名字在這裏就是它的描述, 裏面包含了"或"的意思. 在它的方法參數裏, 有一個標識, 像這樣會改變方法的高級行爲的標識, 一般就意味着該方法會有不止一個職責. 而方法體裏面, 咱們能夠看到它確實有兩個職責, 分別是發送郵件和打電話給客戶.

 

優化後

通過識別, 抽取後, 該類應該分紅下面兩個類:

EmailCommand:

 

 

CallCommand:

 

這個系列的帖子就到這了.

下面開始介紹TDD.