Donald G. Reinertsen, author of “The Principles of Product Development Flow”, asked the question should we assign a resource to a task at the start of a project?
Let’s explore this questions in our software examples below. Will delaying assignment produce light classes, with less memory consumption, and reduced computing waste?
The problem is how can you delay resource demands during object construction? For example, using dependency injection (DI), how do you inject dependencies into a class and delay the construction of these dependencies at the same time?
The solution is to use automatic factories to delay resource demands until it is used.
Download Source Code
Setting the scene
This post will use an illustration of a cloud storage service that relies on an expensive online connection resource. Let’s assume that we cannot modify the constructor behaviour of the resource class.
The interfaces and resource implementation are shown below.
public interface IStorageService
{
void Save(string path, Stream stream);
bool HasSufficientSpace(int requiredSizeMb);
}
public interface IStorageResource
{
void UploadStream(string path, Stream stream);
}
public class CloudStorage : IStorageResource
{
public CloudStorage()
{
Console.WriteLine("Establishing cloud connection...");
// Simulate expensive initialisation
System.Threading.Thread.Sleep(5000);
}
public void UploadStream(string path, Stream stream)
{
// your code here
}
}
public class CloudStorageService : IStorageService
{
private readonly IStorageResource _resource;
public CloudStorageService(IStorageResource resource)
{
if (resource == null) throw new ArgumentNullException("resource");
_resource = resource;
}
public void Save(string path, Stream stream)
{
Console.WriteLine("Called Save");
_resource.UploadStream(path, stream);
}
public bool HasSufficientSpace(int requiredSizeMb)
{
Console.WriteLine("Called HasSufficientSpace");
return true; // No need to check, the cloud service has unlimited space
}
}
Evaluating the results
Let’s run the code and observe the output.
var container = new UnityContainer();
container.RegisterType<IStorageService, CloudStorageService>();
container.RegisterType<IStorageResource, CloudStorage>();
var storageService = container.Resolve<IStorageService>();
if (storageService.HasSufficientSpace(100))
{
using (var fileStream = System.IO.File.OpenRead(@"C:\Temp\File.txt"))
{
storageService.Save(@"Files\File01.txt", fileStream);
}
}
Establishing cloud connection...
Called HasSufficientSpace
Called Save
Oops! The resource was initialised before it was used.
The CloudStorageService class is poorly implemented because:
- The resource dependency is demanded in the constructor causing a significant start-up delay. By default, Windows will refuse to start the service if it takes longer than 30 sec to initialise.
- System memory and computing cycles are wasted since the resource may never be used.
Late binding with an Auto Factory
We are only going to change the CloudStorageService class. Everything else will remain the same, which minimises the risk of potential regression.
The auto factory version is shown below.
public class CloudStorageServiceAutoFactory : IStorageService
{
private readonly Lazy<IStorageResource> _resource;
public CloudStorageServiceAutoFactory(Func<IStorageResource> resource)
{
if (resource == null) throw new ArgumentNullException("resource");
_resource = new Lazy<IStorageResource>(resource);
}
private IStorageResource Resource
{
get { return _resource.Value; }
}
public void Save(string path, Stream stream)
{
Console.WriteLine("Called Save");
Resource.UploadStream(path, stream);
}
public bool HasSufficientSpace(int requiredSizeMb)
{
Console.WriteLine("Called HasSufficientSpace");
return true; // Cloud service has unlimited space
}
}
Note: Unity will automatically pass in a func<IStorageResource> lamba factory function so your bootstrap code doesn’t have to change.
Let’s call the improved CloudStorageServiceAutoFactory class instead.
Called HasSufficientSpace
Called Save
Establishing cloud connection...
Success! The resource demands were deferred until the resource was needed.
Why is this a great solution?
Here is an alternative version as covered in a DevTrends post:
public class CloudStorageServiceBad : IStorageService
{
private readonly Func<IStorageResource> _factory;
private IStorageResource _resource;
public CloudStorageServiceBad(Func<IStorageResource> factory)
{
if (factory == null) throw new ArgumentNullException("factory");
_factory = factory;
}
private IStorageResource Resource
{
get { return _resource ?? (_resource = _factory()); }
}
// The methods goes here
}
Warning! Bad code, do not copy.
The code above is bad because:
- A reference is required to the factory and resource, yet the factory is only used once
- Performing lazy loading in the Resource property is not thread safe
The solution as shown in the CloudStorageServiceAutoFactory class will pass the factory to Lazy<IStorageResource>, which requires less code and is thread safe. See this post about thread safety.
Let’s compare the output of the two solutions by executing the method in multiple threads:
Parallel.Invoke(() => storageService.Save(@"Files\File01.txt", null),
() => storageService.Save(@"Files\File01.txt", null));
CloudStorageServiceBad output:
Called Save
Called Save
Establishing cloud connection...
Establishing cloud connection...
CloudStorageServiceAutoFactory output:
Called Save
Called Save
Establishing cloud connection...
Success! The CloudStorageServiceAutoFactory class is thread safe.
Manual Construction
For those out there who haven’t transitioned to DI yet, but I highly recommend that you do, here is how you would wire it up manually:
var service = new CloudStorageServiceAutoFactory(() => new CloudStorage());
Summary
This post illustrated how to improve memory utilisation and to reduce computing waste using automatic factories to delay expensive resource demands.
Delaying the demand of resources until the code paths are actually executed can significantly improve application performance.