iT邦幫忙

DAY 11
5

如何提升系統設計品質 - 技術與工具以.NET為例系列 第 11

[如何提升系統品質-Day11]重構-使用介面+迴圈取代不穩定的判斷式

今天要分享的部分,是把一陀很類似卻又攤在程式碼中的判斷式,想辦法抽象化。例子會有點像[如何提升系統品質-Day8]重構-簡化判斷式,但相信這次舉的例子會更貼近大家在系統上碰到的需求。

[如何提升系統品質]系列文章連結
需求說明
1.有多筆會員資料要經過多種格式的驗證
2.最後需得到驗證的結果,以及驗證錯誤的訊息

直覺設計出來的原型程式就會長的像下面一樣:

原本的Validation,簡單的做個殼而已。

這邊的程式,至少已經將每個驗證的邏輯抽到了Validation的Class中,將可能變化的驗證邏輯封裝起來。我得強調一下,這樣的程式並沒有『錯』,但這邊提到的是已知未來一定會增加新的驗證邏輯,如何設計面對這樣的需求,不會動到主程式商業邏輯,就是這篇的目的。

重構步驟
步驟一:
首先把我們的眼睛瞇起來一點,(或是你要打開萬花筒寫輪眼、白眼、輪迴眼、血紅眼都可以),用抽象化的方式來看原本的程式,並用自己的話來『說明』這段程式碼。對我來說,原型的程式碼以及設計上的考量,如同下圖:

就算想擷取成介面,也碰到了方法名稱跟參數的type、個數可能不盡相同的困擾。如果介面上開了一堆方法,那就跟原本的Validation沒啥兩樣了。所以,我們要先想個最簡單的介面,也就是這一段一段的if,到底在做什麼?驗證,沒錯,他們都在驗證,只是驗證的東西和邏輯不太一樣。

步驟二:
將驗證的介面定義出來,很簡單,只有一個驗證的方法,回傳bool。而這邊,在驗證後需要知道驗證的錯誤訊息,所以介面就暫訂成下圖:

介面很簡單吧,正因為簡單,所以夠抽象,就能廣泛的重複使用且穩定。

步驟三:
介面已經定義出來了,接下來按照原本的程式碼,我們需要驗證的東西有:
1.Member的Id
2.Member的Email
3.Member的Phone
4.Member的Name

先示範一下MemberIdValidator設計方式:
1.定義好一個MemberIdValidator Class
2.實作IValidator介面
3.將驗證的邏輯寫在Validate的方法中

夠簡單了吧,把驗證錯誤的訊息,記錄在ErrorMessage的屬性,也把驗證是否合法的狀態,記錄在IsValid的屬性中,讓這一個Validator是帶著狀態的。

其他的MemberValidator也都如法炮製,這就是介面的好處,可以讓高階的應用場景抽象地設計高階邏輯,而不用被實作細節侷限住。而實作的細節,又可以達到單一職責原則,內聚力高。在使用上又都透過介面,耦合性低。

步驟四:
重構我們的使用場景,將要驗證Member的各個Validator,加入一個List中,透過foreach,呼叫IValidator的Validate方法,就能將每一種需要驗證的格式都驗證過一遍。

執行結果:

當未來需要增加新的驗證邏輯,則新增一個新的Validator實作IValidator介面即可。要修改特定的邏輯,也只要修改對應的Validator class內部邏輯。如果在不同的狀況,驗證同一種格式,需要有不同的方式,也只要再透過Strategy Pattern就可以輕鬆的抽換驗證邏輯。

結論
這只是個簡單的示範,重點是未來需求異動的機會可能不低,且期望能讓系統架構更穩定一些。否則,其實寫的Code不會比本來少,但乾淨是一定乾淨的多。

這一篇最後重構完的結果,還有其他重構空間,例如:
1.List的資料來源,可以透過資料庫或設定檔,再使用Reflection或工廠模式來產生對應的Validator
2.驗證規則的部分,可能在不同的情況,也可以透過DB來存取Regular expression的規則。讓未來單純更改Regular Expression的Pattern時,由資料來決定邏輯,而不用修改程式。

老話一句,希望這樣的方式,對大家在整理跟重構系統時,會有所幫助。


上一篇
[如何提升系統品質-Day10]重構-合併重複的條件片段
下一篇
[如何提升系統品質-Day12]命名-Glossary的建立
系列文
如何提升系統設計品質 - 技術與工具以.NET為例30

1 則留言

0
chiounan
iT邦研究生 1 級 ‧ 2011-10-21 10:55:45

讚很認真

我要留言

立即登入留言