Is there any guidance or best practices around who should call Dispose()
on disposable objects when they have been passed into another object's methods or constuctor?
Here's a couple of examples as to what I mean.
IDisposable object is passed into a method (Should it dispose of it once its done?):
public void DoStuff(IDisposable disposableObj)
{
// Do something with disposableObj
CalculateSomething(disposableObj)
disposableObj.Dispose();
}
IDisposable object is passed into a method and a reference is kept (Should it dispose of it when MyClass
is disposed?):
public class MyClass : IDisposable
{
private IDisposable _disposableObj = null;
public void DoStuff(IDisposable disposableObj)
{
_disposableObj = disposableObj;
}
public void Dispose()
{
_disposableObj.Dispose();
}
}
I'm currently thinking that in the first example the caller of DoStuff()
should dispose of the object as it probably created the object. But in the second example it feels like MyClass
should dispose of the object as it keeps a reference to it. The problem with this is that the calling class might not know MyClass
has kept a reference and therefore might decide to dispose of the object before MyClass
has finished using it.
Are there any standard rules for this sort of scenario? If there are, do they differ when the disposable object is being passed into a constructor?
Best Answer
Short answer:
Yes, there is much advice on this topic, and the best that I know of is Eric Evans' concept of Aggregates in Domain-Driven Design. (Simply put, the core idea as applied to
IDisposable
is this: Encapsulate theIDisposable
in a coarser-grained component such that it is not seen by the outside and is never passed to the component consumer.)Moreover, the idea that the creator of an
IDisposable
object should also be in charge of disposing it is too restrictive and often won't work in practice.The rest of my answer goes into more detail on both points, in the same order. I'll finish off my answer with a few pointers to further material that is related to the same topic.
Longer answer — What this question is all about in broader terms:
Advice on this topic is usually not specific to
IDisposable
. Whenever people talk about object lifetimes and ownership, they are referring to the very same issue (but in more general terms).Why does this topic hardly ever arise in the .NET ecosystem? Because .NET's runtime environment (the CLR) performs automatic garbage collection, which does all the work for you: If you no longer need an object, you can simply forget about it and the garbage collector will eventually reclaim its memory.
Why, then, does the question come up with
IDisposable
objects? BecauseIDisposable
is all about the explicit, deterministic control of a (often sparse or expensive) resource's lifetime:IDisposable
objects are supposed to be released as soon as they are no longer needed — and the garbage collector's indeterminate guarantee ("I'll eventually reclaim the memory used by you!") simply isn't good enough.Your question, re-phrased in the broader terms of object lifetime and ownership:
Let's establish a few assumptions:
Calling
D.Dispose()
for anIDisposable
objectD
basically ends its lifetime.Logically, an object's lifetime can only be ended once. (Never mind for the moment that this stands in opposition to the
IDisposable
protocol, which explicitly permits multiple calls toDispose
.)Therefore, for the sake of simplicity, exactly one object
O
should be responsible for disposingD
. Let's callO
the owner.Now we get to the core of the issue: Neither the C# language, nor VB.NET provide a mechanism for enforcing ownership relationships between objects. So this turns into a design issue: All objects
O,X,Y,Z
that receive a reference to another objectD
must follow and adhere to a convention that regulates exactly who has ownership overD
.Simplify the problem with Aggregates!
The single best advice that I have found on this topic comes from Eric Evans' 2004 book, Domain-Driven Design. Let me cite from the book:
See how this relates to your issue? The addresses from this example are the equivalent to your disposable objects, and the questions are the same: Who should delete them? Who "owns" them?
Evans goes on to suggest Aggregates as a solution to this design problem. From the book again:
The core message here is that you should restrict the passing-around of your
IDisposable
object to a strictly limited set ("aggregate") of other objects. Objects outside that aggregate boundary should never get a direct reference to yourIDisposable
. This greatly simplifies things, since you no longer need to worry whether the greatest part of all objects, namely those outside the aggregate, mightDispose
your object. All you need to do is make sure that the objects inside the boundary all know who is responsible for disposing it. This should be an easy enough problem to solve, as you'd usually implement them together and take care to keep the aggregate boundaries reasonably "tight".What about the suggestion that the creator of an
IDisposable
object should also dispose it?This guideline sounds reasonable and there's an appealing symmetry to it, but just by itself, it often won't work in practice. Arguably it means the same as saying, "Never pass a reference to an
IDisposable
object to some other object", because as soon as you do that, you risk that the receiving object assumes its ownership and disposes it without your knowing.Let's look at two prominent interface types from the .NET Base Class Library (BCL) that clearly violate this rule of thumb:
IEnumerable<T>
andIObservable<T>
. Both are essentially factories that returnIDisposable
objects:IEnumerator<T> IEnumerable<T>.GetEnumerator()
(Remember that
IEnumerator<T>
inherits fromIDisposable
.)IDisposable IObservable<T>.Subscribe(IObserver<T> observer)
In both cases, the caller is expected to dispose the returned object. Arguably, our guideline simply doesn't make sense in the case of object factories... unless, perhaps, we require that the requester (not its immediate creator) of the
IDisposable
releases it.Incidentally, this example also demonstrates the limits of the aggregate solution outlined above: Both
IEnumerable<T>
andIObservable<T>
are way too general in nature to ever be part of an aggregate. Aggregates are usually very domain-specific.Further resources and ideas:
In UML, "has a" relationships between objects can be modelled in two ways: As aggregation (empty diamond), or as composition (filled diamond). Composition differs from aggregation in that the contained/referred object's lifetime ends with that of the container/referrer. Your original question has implied aggregation ("transferable ownership"), while I've mostly steered towards solutions that use composition ("fixed ownership"). See the Wikipedia article on "Object composition".
Autofac (a .NET IoC container) solves this problem in two ways: either by communicating, using a so-called relationship type,
Owned<T>
, who acquires ownership over anIDisposable
; or through the concept of units of work, called lifetime scopes in Autofac.Regarding the latter, Nicholas Blumhardt, the creator of Autofac, has written "An Autofac Lifetime Primer", which includes a section "IDisposable and ownership". The whole article is an excellent treatise on ownership and lifetime issues in .NET. I recommend reading it, even to those not interested in Autofac.
In C++, the Resource Acquisition Is Initialization (RAII) idiom (in general) and smart pointer types (in particular) help the programmer get object lifetime and ownership issues right. Unfortunately, these are not transferrable to .NET, because .NET lacks C++'s elegant support for deterministic object destruction.
See also this answer to the question on Stack Overflow, "How to account for disparate implementation needs?", which (if I understand it correctly) follows a similar thought as my Aggregate-based answer: Building a coarse-grained component around the
IDisposable
such that it is completely contained (and hidden from the component consumer) within.