Using lazy initialization in C#, a class’s state is set up such that each property’s get method performs a check to see if the underlying field is null. If it is, then it calculates or populates the field before returning it. This is a very simple and common approach, but it requires that the class follows a convention of only accessing the field via the property. Unfortunately, there are no language features that can enforce this, so it’s possible for errors to creep in. Here’s an example of this approach working correctly:
Now here’s where this approach can break down. Consider the same class as above, but with a rewritten PrintLabel() method:
This code will still compile just fine, but now will very likely result in a NullReferenceException when it attempts to access properties of the _customer, which may not yet be initialized. The solution to this would be to control access to the _customer member. We’ve already set its access to private, though, which is as restrictive as we can make it. We could force it to be initialized by moving the work into the class’s constructor, but then we’re losing the benefits of lazy initialization. I wonder if it wouldn’t be useful to do something like this instead:
One approach that can be used with the relatively new Lazy<T> type is this one (thanks to Jose Romanie for pointing this out):
I like this approach, and I’m generally a fan of Lazy<T>. It might eliminate the need for the private backing field idea for properties, as it does provide a means of enforcing the initialization even if the backing field is accessed from within the class. The only downside is that you need to work with a Lazy<T> instead of a T, but within the class it’s probably not a bad thing for this detail to be exposed. Thoughts?