Question

我试图在SO上找到类似的问题，但没有运气。如果它是重复的，请道歉。

声明类型变量时，实例化什么是缺点？

在许多代表业务对象模型的类中，我们有这样的事情：

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。无论属性是否水合，它们永远不会对消费阶层“无效”。如果未初始化属性，则代码在访问属性之前每次都需要检查null。

一个总括约定“一个类的所有属性应该始终初始化并且永远不会为空”真的很糟糕吗？

除了使用一些资源来实例化和存储这些“默认”类实例之外，null异常检查代码的节省似乎也是值得的。我们错过了什么吗？

Answer 1

此处不是专家，但

如果是List，则需要初始化，因为如果不是，则无法添加元素。
如果在课程的整个生命周期内，可能并不总是需要您的属性，则可以延迟加载。

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

来自Msdn：“使用Lazy实例推迟创建大型或资源密集型对象或执行资源密集型任务，尤其是在生命周期内不会发生此类创建或执行时该计划。“

除此之外，我认为所有属性都是密集的，并且让每个消费类都进行空检查。 Lazy<T>解决了这个问题。

Answer 2

我喜欢初始化值以避免在整个应用程序中检查null。我可能会选择延迟加载：

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

Answer 3

只要您的属性只是列表（如您的示例中所示），它可能是一个很好的约定，使您的代码更紧凑，更易于阅读。列表可以为空，如果您不需要区分空列表和空引用，这可以正常工作。但是，如果您的属性包含其他“Business Objects”，则可能无法轻松实现。通常，在构建“父”对象时，不能或不应该构建那些“子”业务对象。

是否应始终初始化Model类的复合属性？

3 个答案: