面向對象設計 - 何處/何時驗證屬性？

是的「的isValid」的定義是相當一個令人困惑的領域。這個問題似乎需要爲了可靠一些背景 - 我發現自己寫的東西，如：命令中─> IsValidOrderAccordingToPaymentStrategy（）希望聽到經典的一本書對這個話題，每個人，但我似乎已經閱讀。 – 2010-04-09 19:15:57

在多個地方驗證似乎是個不錯的主意。首先，你有重複的代碼來維護。此外，從概念上講，如果你有一個牛的對象，牛應該知道什麼是有效的食物投入 - 你不希望世界上的每一個植物都證實自己是可以接受的牛食品。讓牛決定。 – 2010-04-09 19:17:01

但你不一定要把你的牛放到充滿有毒蘑菇的牧場上，即使合理確定你的牛不會吃它們。 :) – sweaver2112 2010-04-09 20:14:01

OOP的一個重要組成部分始終保持您的對象處於有效狀態。因此，應該在可以修改對象的輸入之後進行驗證。

驗證從屬性/集合，參數到函數和構造函數的數據是很好的。

來源

2010-04-09 19:15:21 ALOToverflow

「OOP的一個重要部分是始終保持您的對象在一個有效的狀態」 - 我喜歡這個，謝謝。 – Jimbo 2014-11-28 13:24:13

區分域對象的不變量（必須始終滿足）和有人稱之爲「contextual validation."例如，具有負面銀行帳戶的客戶是否無效」這一點非常重要？「否，但是他們可能無權執行某些類型的交易。這是上下文驗證，與「每個客戶實體必須具有非空ID」相反，這是完全不同類型的驗證。執行不變量

一種有效的方法是在域對象區分表示域對象的用戶輸入，並且不暴露無限制增變器（組簡單的存取，例如）類。

舉例來說，如果你有一個Student域對象，不直接在用戶界面中進行操作。您的視圖不會創建Student實例，而是創建StudentBuilder實例，這些實例將模擬構建有效的域對象所需的內容。

接下來，你有驗證建設者實例符合域對象的不變量類，和工廠是需要接受的建設者和可以將其轉化爲有效的域對象。（您也可以在此步驟中適當引入上下文驗證策略。）

來源

2010-04-09 19:22:51

是的，這似乎是有道理的。我通過創建一個'規範對象'或'數據籠'來容納傳入數據來做到這一點 - 但之前並不確定。 – 2010-04-09 19:32:17

這取決於你的編程風格，維基百科有更詳細的解釋，我將只是劃傷表面，並鏈接到維基百科。（是的，我懶:-)）。

注：所有這一切並不適用於用戶輸入。你必須以任何方式驗證它。我只是談論業務邏輯類，它不應該以任何方式與用戶輸入相結合。 :-)

防守

正如其他人所說，你將執行每個屬性的邊界。我經常拋出運行時異常（Java）來表明這些失敗。

Wikipedia on Defensive Programming

通過合同

您記錄您的代碼的要求和承擔，例如，傳遞給你制定者的值是有效的關於所定義的合同。這爲您節省了很多樣板代碼。但是當發現非法價值時，尋找錯誤將會更加困難。

Wikipedia on Design by Contract

來源

2010-04-09 19:30:04 Malax

我發現Design By Contract（TM）信息非常有用 - 特別是'失敗'的想法，這似乎是所有這些答案的運行主題。讓供應商的工作儘可能簡單，並讓客戶決定在價值被拒絕時應該怎麼做。 – 2010-04-09 20:59:53

面向對象設計 - 何處/何時驗證屬性？

回答

相關問題