Inner Fields and Lazy Initialization in C#

Oct 29 2011 7:25 AM

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:

public class Order
{
    // other properties
 
    private Customer _customer;
    public Customer Customer
    {
        get
        {
            if (_customer == null)
            {
                _customer = new Customer();
            }
            return _customer;
        }
    }
 
    public string PrintLabel()
    {
        return Customer.CompanyName + "\n" + Customer.Address;
    }
}

Now here’s where this approach can break down.  Consider the same class as above, but with a rewritten PrintLabel() method:

public string PrintLabel()
{
  return _customer.CompanyName + "\n" + _customer.Address;
}

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:

public class Order
{
    // other properties
 
    private Customer _customer;
    public Customer Customer
    {
        get
        {
            if (_customer == null)
            {
                _customer = new Customer();
            }
            return _customer;
        }
    }
 
    public string PrintLabel()
    {
        string result = _customer.CompanyName; // probably results in a NullReferenceException
        return result + "\n" + Customer.Address; // ok to access Customer
    }
}
 
We already have auto-properties in C# that avoid the need for having backing fields in the default case.  I think being able to protect access to backing fields so that they can be configured to only be accessible by their property would be quite useful in a number of cases, including this very common one.  I also don’t believe this would break any existing code or change the language in a way that would make it less easy to understand.  What do you think, is this something the C# team should consider adding in a future version of the language?

One approach that can be used with the relatively new Lazy<T> type is this one (thanks to Jose Romanie for pointing this out):

public class Order
{
    public Order()
    {
        _customerInitializer = new Lazy<Customer>(() => new Customer());
    }
 
    // other properties
 
    private Lazy<Customer> _customerInitializer;
    public Customer Customer
    {
        get
        {
            return _customerInitializer.Value;
        }
    }
 
    public string PrintLabel()
    {
        string result = Customer.CompanyName; // ok to access Customer
        return result + "\n" + _customerInitializer.Value.Address; // ok to access via .Value
    }
}

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? 

blog comments powered by Disqus