optimization - private用法 - when to use getters and setters




數據驗證在Getter/Setter或其他地方? (6)

我想知道是否在gettersetter或代碼中的其他地方進行驗證是一個好主意。

這可能會讓你感到驚訝,當談到優化加速代碼時,我認為你不應該在getter和setter中進行驗證,而應該在你正在更新文件或數據庫的代碼中進行驗證。 我錯了嗎?


你可能想看一下Eric Evans的Domain Driven Design 。 DDD有這樣一個規範的概念:

用於專門用途的顯式謂詞類型VALUE OBJECTS SPECIFICATION是一個謂詞,用於確定某個對像是否滿足某些條件。

我認為快速失敗是一回事,另一個是保持驗證邏輯的地方。 該域是保持邏輯的正確位置,我認為在您的域對像上的規範對像或驗證方法將是一個好地方。


這取決於。

一般來說,代碼應該快速失敗。 如果該值可以通過代碼中的多個點設置,並且僅在檢索該值後驗證,則該錯誤似乎位於執行更新的代碼中。 如果設置者驗證輸入,則知道代碼嘗試設置無效值。


驗證應該在驗證方法中與獲取者或設置者分開獲取。 這樣,如果驗證需要在多個組件中重用,則可以使用。

當調用者被調用時,應使用這種驗證服務來消除對對象的輸入。 這樣你就知道存儲在一個對像中的所有信息都是有效的。

您不需要對getter進行任何驗證,因為對像上的信息已被信任為有效。

不要保存你的驗證,直到數據庫更新! 快速失敗會更好。


從擁有最可維護的代碼的角度來看,我認為你應該盡可能多地在屬性的設置者中進行驗證。 這樣你就不會緩存或以其他方式處理無效數據。

畢竟,這是屬性的意思。 如果你擁有的是一堆像...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

他們也可能是田野


@Terrapin,重新:

如果你擁有的只是一堆(簡單的公共設置/獲得)屬性...他們也可能是領域

屬性比字段有其他優點。 它們是一個更明確的契約,它們是序列化的,可以稍後調試,它們是通過繼承進行擴展的好地方。 笨重的語法是一個意外的複雜性 - 例如.net 3.5克服了這一點。

一個常見的(有缺陷的)做法是從公共領域開始,然後在“根據需要”的基礎上把它們變成屬性。 這違反了你的任何消費類的人的合同,所以最好從屬性開始。


我盡量不要讓我的對象進入一個無效的狀態,所以setter肯定會有驗證以及任何改變狀態的方法。 這樣,我就不用擔心我處理的對像是無效的。 如果您將方法保留為驗證邊界,那麼您就不必擔心驗證框架和IsValid()方法調用遍布整個地方。





verification