Should the composite properties of the Model class always be displayed?

Question

I tried to find a similar question on SO, but no luck. Sorry if this is a duplicate.

What are the disadvantages of instantiating class type variables when they are declared?

In many of the classes that represent the Business Object Model, we have these things:

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 idea is that we create "empty" class instances so that no properties are ever null . This is convenient because we never need to check if any property is null before accessing them. Whether the properties are hydrated or not, they will never be “null” for the class of consumption. If the properties are not initialized, then the code should check for null each time before accessing the property.

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

Besides using some resources to instantiate the default class, the cost savings in the code for checking exception exceptions seem to be worth it. Are we missing something?

Answer 1

There is no expert, but

• If it is a list, it needs to be initialized, since you cannot add items if it is not.
• If throughout the life of your class your properties may not always be necessary, you can lazy load .

You can use the .Net 4.0 Lazy<T> class.

From Msdn: "Use a Lazy instance to defer the creation of a large or resource-intensive object or to perform a resource-intensive task, especially if such creation or execution may not occur throughout the entire program life cycle."

In addition, I think it would be very difficult for all of your properties, and each consumption class performs zero checks. Lazy<T> solves this.

Answer 2

I like to initialize the values ​​to avoid having to check for null throughout the application. I would probably go with lazy loading:

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

Answer 3

As long as your properties are just lists (as in your example), this may be a good convention, making your code more compact and easier to read. Lists can be empty, and if you do not need to distinguish between an empty list and a null link, this works fine. But if your properties contain other "Business Objects", this may not be so simple. Often, the construction of these "child" business objects cannot or should not be performed at the time the "parent" object is created.