Should composite properties of a Model class be always initialized?

I tried to find a similar question on SO but had no luck. Apologies if it's a duplicate.

What are drawbacks to in开发者_高级运维stantiating class-type variables when they are declared?

In a lot of classes representing Business Object Model we have things like this:

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; }
    }
}

At some point this PricingData class is initialized and some properties are hydrated (but not always all properties).

The thinking being that we're creating "blank" instances of classes so that no properties are ever null. This is convenient because we never have to check if any property is null before accessing it's members. Whether properties are hydrated or not, they would never be "null" to the consuming class. If the properties aren't initialized then code needs to check for null every time before accessing a property.

Is a blanket convention that "all properties of a class should be initialized at all times and never be null" really bad?

Besides using some resources to instantiate and store these "default" class instances, the savings in null-exception-checking code seem to be worth it. Are we missing something?

Not an expert here but

1. If its a List, it does need to be initialized since you can't add elements if it isn't.
2. If, throughout the life of your class, your properties may not be always needed you can lazy load them.

You could use .Net 4.0's Lazy<T> class.

From Msdn : "Use an instance of Lazy to defer the creation of a large or resource-intensive object or the execution of a resource-intensive task, particularly when such creation or execution might not occur during the lifetime of the program."

Other than that I think it would be intensive for all your properties to be null and have every consuming class do null checks. Lazy<T> solves this.

I like to initialize values to avoid having to check for null throughout my application. I'd probably go with lazy loading:

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

As long as your properties are only lists (as in your example), it may be a good convention, making your code more compact and easier to read. Lists can be empty, and if you don't need to distinguish between an empty list and a null reference, this works fine. But if your properties contain other "Business Objects", this may not work so easily. Often the construction of those "child" Business Objects cannot or shall not be done at the time when the "parent" object is constructed.