Decommissioning Decoraptors by Mark Seemann
How to release objects from within a Decoraptor.
In my article about the Decoraptor design pattern, I deliberately ignored the question of decommissioning: what if the short-lived object created inside of the Decoraptor contains one or more disposable objects?
A Decoraptor creates instances of object graphs, and such object graphs may contain disposable objects. These disposable objects may be deeply buried inside of the object graph, and the root object itself may not implement IDisposable.
This is a know problem, and the solution is known as well: the object that composes the object graph is the only object with enough knowledge to dispose of any disposable objects within the object graph that it created, so an Abstract Factory should also be able to release objects again:
public interface IFactory<T> { T Create(); void Release(T item); }
This is similar to advice I've already given in conjunction with designing DI-Friendly frameworks.
Example: refactored Decoraptor #
With the new version of the IFactory<T> interface, you can refactor the Observeraptor class from the Decoraptor article:
public class Observeraptor<T> : IObserver<T> { private readonly IFactory<IObserver<T>> factory; public Observeraptor(IFactory<IObserver<T>> factory) { this.factory = factory; } public void OnCompleted() { var obs = this.factory.Create(); obs.OnCompleted(); this.factory.Release(obs); } public void OnError(Exception error) { var obs = this.factory.Create(); obs.OnError(error); this.factory.Release(obs); } public void OnNext(T value) { var obs = this.factory.Create(); obs.OnNext(value); this.factory.Release(obs); } }
As you can see, each method implementation now performs three steps:
- Use the factory to create an instance of IObserver<T>
- Delegate the method call to the new instance
- Release the short-lived instance
Some people prefer letting the factory return something that implements IDisposable, so that the Decoraptor can employ a using statement in order to manage the lifetime of the returned object. However, IObserver<T> itself doesn't derive from IDisposable, so if you want to do something like that, you'd need to invent some sort of Scope<T> class, which would implement IDisposable; that's another alternative.
Example: refactored factory #
Refactoring the Decoraptor itself to take decommissioning into account is fairly easy, but you also need to implement the Release method on any factory implementations. Furthermore, the factory should be thread-safe, because often, the entire point of introducing a Decoraptor in the first place is to deal with Services that aren't thread-safe.
Implementing a thread-safe Composer isn't too difficult, but certainly increases the complexity of it:
public class SqlMeterFactory : IFactory<IObserver<MeterRecord>> { private readonly ConcurrentDictionary<IObserver<MeterRecord>, MeteringContext> observers; public SqlMeterFactory() { this.observers = new ConcurrentDictionary<IObserver<MeterRecord>, MeteringContext>(); } public IObserver<MeterRecord> Create() { var ctx = new MeteringContext(); var obs = new SqlMeter(ctx); this.observers[obs] = ctx; return obs; } public void Release(IObserver<MeterRecord> item) { MeteringContext ctx; if (this.observers.TryRemove(item, out ctx)) ctx.Dispose(); } }
Fortunately, instead of having to handle the complexity of a thread-safe implementation, you can delegate that part to a ConcurrentDictionary.
Disposable graphs #
The astute reader may have been wondering about this: shouldn't SqlMeter implement IDisposable? And if so, wouldn't it be easier to simply dispose of it directly, instead of having to deal with a dictionary of root objects as keys, and disposable objects as values?
The short answer is that, in this particular example, this would indeed have been a more correct, as well as a simpler, solution. Consider the SqlMeter class:
public class SqlMeter : IObserver<MeterRecord> { private readonly MeteringContext ctx; public SqlMeter(MeteringContext ctx) { this.ctx = ctx; } public void OnNext(MeterRecord value) { this.ctx.Records.Add(value); this.ctx.SaveChanges(); } public void OnCompleted() { } public void OnError(Exception error) { } }
Since SqlMeter has a class field of the type MeteringContext, and MeteringContext, via deriving from DbContext, is a disposable object, SqlMeter itself also ought to implement IDisposable.
Yes, indeed, it should, and the only reason I didn't do that was for the sake of the example. If SqlMeter had implemented IDisposable, you'd be tempted to implement SqlMeterFactory.Release by simply attempting to downcast the incoming item from IObserver<MeterRecord> to IDisposable, and then, if the cast succeeds, invoke its Dispose method.
However, the only reason we know that SqlMeter ought to implement IDisposable is because it has a concrete dependency. Concrete types can implement IDisposable, but interfaces should not, since IDisposable is an implementation detail. (I do realize that some interfaces defined by the .NET Base Class Library derives from IDisposable, but I consider those Leaky Abstractions. As Nicholas Blumhardt put it: "an interface [...] generally shouldn't be disposable. There's no way for the one defining an interface to foresee all possible implementations of it - you can always come up with a disposable implementation of practically any interface.")
The point of this discussion is that as soon as a class has an abstract dependency (as opposed to a concrete dependency), the class may or may not be relying on something that is disposable. That's not enough to warrant the class itself to implement the IDisposable interface. For this reason, when an Abstract Factory creates an object graph, the root object of that graph should rarely implement IDisposable, and that's the reason it's not enough to attempt a downcast.
This was the reason that I intentionally didn't implement IDisposable on SqlMeter, even though I should have: to demonstrate how a Release method should deal with object graphs where the disposable objects are deeply buried as leaf nodes in the graph. A Release method may not always be able to traverse the graph, so this is the reason that the factory must also have the decommissioning responsibility: only the Composer knows what it composed, so only it knows how to safely dismantle the graph again.
Summary #
Throwing IDisposable into the mix always makes things much more complicated, so if you can, try to implement your classes in such a way that they aren't disposable. This is often possible, but if you can't avoid it, you must add a Release method to your Abstract Factory and handle the additional complexity of decommissioning object graphs.
Some (but not all!) DI Containers already do this, so that may be one reason to use a DI Container.
