嗯,這是一段時間以來這個問題被張貼,但我想給一個不同的角度對這個話題。
使用你發佈的具體例子,恕我直言,你應該做驗證,但以不同的方式。
實現驗證的關鍵在於問題本身。想想看:你在處理的是名字,而不是字符串。 字符串是非空名稱。我們還可以考慮使字符串成爲名稱的其他特徵:不能爲空也不能包含空格。
假設您需要添加這些驗證規則:如果您堅持使用您的方法,您會像@SingleShot所說的那樣結束混亂。
另外,如果多個域對象有一個setName setter,你會怎麼做? 即使您使用助手類作爲@dave,代碼仍會被複制:調用助手實例。
現在,想一想:如果您在setName方法中能夠接收到的所有參數都有效,該怎麼辦?當然不需要驗證。 我聽起來過於樂觀,但可以做到。
記住你正在處理的名稱,所以爲什麼不建模名稱的概念? 這裏的香草,虛擬實現,以顯示想法:
public class Name
public static Name From(String value) {
if (string.IsNullOrEmpty(value)) throw new ...
if (value.contains(' ')) throw new ...
return new Name(value);
}
private Name(string value) {
this.value = value;
}
// other Name stuff goes here...
}
因爲驗證在制定的過程中發生的事情,你只能得到有效的名稱實例。無法從「無效」字符串創建名稱實例。 不僅驗證代碼已經集中,而且在對它們有意義的上下文中引發異常(創建Name實例)。
您可以閱讀Hernan Wilkinson的「巴塔哥尼亞背後的設計原理」中的偉大設計原則(該名稱示例源自它)。請務必檢查ESUG 2010 Video和presentation slides
最後,我想你可能會發現Jim Shore的文章"Fail Fast"有趣。
看起來您的質量檢查人員沒有針對這些支票投放分支獲得單元測試覆蓋率。你應該告訴他們停止懶惰,並且將其包含在測試中,因爲它應該是。 – 2009-10-30 19:59:59
單元測試?我們不需要單元測試......(我知道,我知道,但我不能改變一切......) – 2009-10-30 20:03:27