情境驗證

在我寫作的過程中，我早就打算寫一大段關於驗證的內容。這是一個容易讓人感到困惑的領域，而對於一些運作良好的技術，能有明確的說明將會是一件好事。然而，生活中有太多事情值得寫，而時間卻不夠用。

最近讀了一些文章，讓我想先對這個主題說一些初步的想法。我常看到人們會為物件開發驗證例程。這些例程有各種形式，它們可能在物件中或外部，它們可能會傳回布林值或擲回例外狀況來表示失敗。但我認為會讓大家一直絆倒的一件事，就是當他們以isValid方法暗示物件有效性時，會以與情境無關的方式來思考。

我認為將驗證視為與情境相關的事物會更有用，通常是您想要執行的動作。這個訂單是否有效可以填寫，這個客戶是否有效可以入住飯店。因此，不要使用isValid之類的方法，而是使用isValidForCheckIn之類的方法。

這樣做的一個後果是，將物件儲存到資料庫中本身就是一個動作。從這個角度思考會產生一些重要問題。通常，當人們談論與情境無關的有效性時，他們的意思是儲存到資料庫中。但組成這個有效性的各種驗證檢查應以「失敗這個測試是否應阻止儲存？」這個問題來審查。

在About Face中，艾倫·庫珀主張我們不應該讓我們的有效狀態觀念阻止使用者輸入（並儲存）不完整的資訊。幾天前，我在閱讀吉米·尼爾森正在撰寫的一本書草稿時，想起了這一點。他提出一個原則，您應該始終可以儲存物件，即使其中有錯誤。雖然我不確定這是否應該成為絕對的規則，但我確實認為人們往往會過度阻止儲存。思考驗證的情境可能有助於防止這種情況。

於 2011 年 11 月 3 日重新發布