I’m implementing a .NET class which implements IDisposable. After being disposed, the object’s state is invalid and so nobody should be accessing it, of course.
There are some situations where two essentially independent systems have access to the same instance of this class. One essentially “owns” the object but the other is charged with interacting with the object in a persistent manner.
If the “owner” opts to get rid of the object by calling Dispose on it, the other system needs to know about this because otherwise it may try to interact with an invalid object. It is not always convenient to have the owner inform the other system to stop using the object, because the owner itself may not know about this other system.
I do have the class implementing an IsDisposed property, but there are situations where polling this would become impractical and it would be preferable for the “non-owner” to instead receive notification that the object is disposed.
To this end I figured that implementing a Disposing event on the class would be a good solution, but this leads to some design questions:
-
Is the instance considered to already have been disposed at the time the event is raised? (My guess would be that it should be regarded as alive until the handlers finish.)
-
How should the object react to further manipulation that occurs inside the event handlers? (My guess is react in the usual manner for a living object since it is still alive.)
-
What if a handler itself calls Dispose on the object? (We could either explicitly ignore re-entrant calls or just assume that well-behaved handlers won’t do this.)
-
Should the Disposed event still be raised in the event of the object being finalized without having ever been explicitly disposed? (I can’t think of a case off hand where such an event would actually be needed, and it definitely has the potential to cause problems.)
I’m wondering if there is any established wisdom on how this pattern should be designed in general, or any examples I should be aware of where trouble is likely.
3
Linq to SQL had a related issue, having to do with lazy evaluation. If data was requested after the DataContext was disposed (which can happen if the query is lazily evaluated), an exception was thrown.
The solution was to not dispose of the data context, and allow the garbage collector to collect it naturally. See http://leedumond.com/blog/about-disposing-the-datacontext/
Strictly speaking, you do not need the dispose pattern unless you are holding unmanaged resources. Unmanaged resources are not automatically cleaned up by the garbage collector, so you have to do that yourself. Of course, this hasn’t prevented some very smart people from abusing the using pattern for fun and profit.
All that said, I don’t see any reason why you couldn’t fire an event from the Dispose() method. You can pass the object being disposed through the event handler and, as long as your event handler doesn’t hold onto the object for too long, dispose of your managed resources when the handler returns.
1
I’m pretty sure it’s in the Framework Design Guidelines somewhere, but what I’ve observed is that whenever an object gives you a Disposable, it does not interact with it anymore. Usually, there is a static method call that is responsible for creating and handing the disposable to you.
There are two options you have here:
-
Your “owner” should never expose the IDisposable and should instead act as an Adapter over it. (In other words the client calls the “owner” who then delegates the calls to the IDisposable).
-
Your “owner” should be a factory and should just be responsible for creating an instance of the IDisposable, doing any additional configuration, and handing it to the client never storing a reference to it.
1