The Generic Lazy Type

Lazy<T> is a monad type that was introduced in .NET 4 and provides an alternative mechanism for implementing lazy initialization. Lazy initialization is where you intentionally delay the creation of an object that is expensive to create.

You would typically want to use lazy initialization in scenarios where the object (which is expensive to create) may or may not be used in the execution flow of your program. In this case, it makes sense to only initialize the object if it is required. One reliable place where you may have seen the lazy initialization tactic being used is in an implementation of a singleton class – which will have a method or property that returns the singleton instance, for example,

public MySingletonClass GetInstance()
{
if (_singleton == null)
_singleton = new MySingletonClass();
return _singleton;
}

The logic before the return statement is an example of lazy initialization, where the singleton is only instantiated the first time GetInstance is called and never before it. Subsequent calls to GetInstance will then also return the same instance, hence we have an implementation of the singleton design pattern. In this particular case, we don’t know if MySingletonClass is expensive to create, and we don’t particularly care as we’re using lazy initialization to prevent multiple instances of MySingletonClass from being created.

If we now go back to the mainstream use for lazy initialization, where we want to delay instantiation of expensive-to-create objects, you could adapt the pattern above where you conditionally instantiate an instance of an object. However, since .NET 4, you have an alternative option with the use of Lazy<T>. An instance of Lazy<T> wraps around your expensive-to-create object, you pass this instance around in your code and whenever the underlying expensive-to-create object is required, you can call the Value property on Lazy<T> which will instantiate the object and return it to you.

The following contrived example should make it more clear. Imagine you have a Customer class and an Order class. A single customer can have many orders, so we’ll make use of composition and have the Customer class support a List of Order objects. The Customer class has one constructor that accepts a customer ID. Using the supplied ID, the constructor then goes and retrieves the orders for the customer from an order repository. Note that in reality your entity classes will usually be dumb and just support getter and setter properties and it’ll be the responsibility of your data access layer/framework (like Entity Framework) to instantiate and populate your entities appropriately. Continuing with our contrived example, our initial attempt may, therefore, look like,

public class Order { }
public class Customer
{
public int Id { get; private set; }
public string Name { get; set; }
public List<Order> Orders { get; set; }
public Customer(int id)
{
Id = id;
Name = "Ms Foo Bar";
// Simulate getting lots of orders from an
// order repository
Orders = Enumerable
.Repeat<Order>(new Order(), 200)
.ToList();
}
public override string ToString()
{
return string.Format(
"I'm customer with id {0}", Id);
}
}

As the code indicates, it would be expensive to instantiate a Customer object if we didn’t require the order information contained within it. This is where you would apply the concept of lazy initialization. In this case, we’ll make use of the Lazy<T> type. The following code shows how the Customer class would look if we lazily instantiate the Orders list using Lazy<T>.

public class Customer
{
public int Id { get; private set; }
public string Name { get; set; }
public Lazy<List<Order>> Orders { get; set; }
public Customer(int id)
{
Id = id;
Name = "Ms Foo Bar";
Orders = new Lazy<List<Order>>(() => {
// Simulate getting lots of orders from an
// order repository
return Enumerable
.Repeat<Order>(new Order(), 200)
.ToList();
}
);
Debug.WriteLine(this);
}
public override string ToString()
{
return string.Format(
"I'm customer with id {0}", Id);
}
}

As you can see, the constructor of the Customer class instantiates an instance of Lazy<T> that wraps around the List of Order objects. The constructor of Lazy<T> is passed a lambda expression that expresses what needs to be returned when the list of orders is requested for (our expensive logic). Notice I’ve also put a call to Debug.WriteLine so you can observe the output of the following code and see how this behaves.

var customer = new Customer(1);

Debug.WriteLine("Are orders instantiated? {0}",
customer.Orders.IsValueCreated);
// Ok, we now want the orders...
var ordersForCustomer = customer.Orders.Value;
Debug.WriteLine("Are orders instantiated? {0}",
customer.Orders.IsValueCreated);
Debug.WriteLine("Customer {0} has {1} order(s)",
customer.Id, ordersForCustomer.Count);

If you execute the code above using the updated Customer class, you’ll find that instantiating a Customer object is no longer an expensive operation. The output you should see in your debug window is,

I'm customer with id 1
Are orders instantiated? F
alse Are orders instantiated?
True Customer 1 has 200 order(s)

Notice that when the Customer object was initialized, the runtime executed the constructor logic as expected (verifiable with the ToString output). We then check our Lazy objects IsValueCreated property to ensure it hasn’t yet created an instance of the list and populated it. The property returned False as expected. On the next line, we explicitly call the Value property on the Orders property (our Lazy object) – this forces our lazy object to instantiate.

We re-query the IsValueCreated property which now returns True and finally, we output the order count to show that the orders have been successfully lazily-loaded.