應該始終初始化Model類的組合屬性？

我試圖在SO上找到類似的問題，但沒有運氣。道歉，如果它是重複的。應該始終初始化Model類的組合屬性？

有什麼缺點實例類類型的變量在聲明時？

在大量的代表業務對象模型類的，我們有這樣的事情：

public class RateArea {...} 
public class FlatRateSchedule 
{ 
    public string ScheduleID {get;set;} 
    public decimal MaxAmount {get;set;} 
} 

public class PricingData 
{ 
    private List<RateArea> rateAreaList = new List<RateArea>(); 
    private FlatRateSchedule flatRateSchedule = new FlatRateSchedule(); 

    public List<RateArea> RateAreaList 
    { 
     get { return rateAreaList; } 
     set { rateAreaList = value; } 
    } 

    public List<FlatRateSchedule> FlatRateScheduleList 
    { 
     get { return flatRateScheduleList; } 
     set { flatRateScheduleList = value; } 
    } 
}

在某些時候，這個PricingData類初始化和某些屬性水合（但不總是所有屬性）。

的想法是，我們正在創建的類「空白」實例，以便沒有屬性是有史以來null。這很方便，因爲我們在訪問它的成員之前不必檢查任何屬性是否爲空。無論物業是否保水，他們永遠不會對消費階層「空洞」。如果屬性沒有被初始化，那麼代碼在訪問屬性之前需要每次檢查null。

是一種全面的約定「一類的所有屬性都應該在任何時候都被初始化，不能爲空」非常糟糕？

除了使用一些資源來實例化和存儲這些「默認」類的實例，在零異常檢查代碼的儲蓄似乎是值得的。我們錯過了什麼嗎？

來源

2011-03-17 Leon

這裏不是專家，但

如果它是一個列表，因此它需要被初始化，因爲你不能添加元素，如果它不是。
如果，整個班級的生活，你的屬性可能不會總是需要的，你可以懶加載他們。

您可以使用.Net 4.0的Lazy<T>類。

來自Msdn：「使用Lazy實例推遲創建大型資源密集型對象或執行資源密集型任務，特別是在創建或執行過程可能不會發生在程序。」

除此之外，我認爲這將是密集的所有屬性爲空，完全有消費類做null檢查。 Lazy<T>解決了這個問題。

來源

2011-03-17 14:40:20 gideon

Lazy類的好主意。 – neontapir 2011-03-17 14:41:44

這減輕了我的顧慮。我們將業務對象發送到Web服務，它們是簡單的DTO類型的對象，沒有邏輯。對象在數據層中被水化，並且沒有辦法自我保護。 – Leon 2011-03-21 14:36:15

我喜歡初始化值以避免在整個應用程序中檢查null值。我大概有延遲加載去：

public List<RateArea> RateAreaList 
{ 
    get { 
     rateAreaList = rateAreaList ?? new List<RateArea>(); 
     return rateAreaList; 
    } 
    set { rateAreaList = value; } 
}

來源

2011-03-17 14:41:23 neontapir

只要你的屬性僅列表（如你的例子），它可能是一個好習慣，使你的代碼更緊湊，更易於閱讀。列表可以是空的，如果你不需要區分空列表和空引用，這可以正常工作。但是，如果您的屬性包含其他「業務對象」，這可能無法如此輕鬆地工作。通常，在構建「父」對象時，這些「子」Business Objects的構建不能或不應該完成。

來源

2011-03-17 14:46:21

應該始終初始化Model類的組合屬性？

回答

相關問題