[.net] Implementing Dispose()

Technically B still holds a reference to A, you might want to add a "A = null" in the dispose. I really dont see a problem here, the reference to A in C after B is disposed is still valid.

Dispose != finalize, finalization will only happen after all references are gone, supressing finalization simply tells the GC that yes, there is unmanaged data but I have already take care of it so you dont have to call finalize ( or the deconstructor ) which adds some overhead in the GC when actually destroying an object. Try putting some debug output in both the dispose and finalize functions of all your classes to see the order things happen.

If ClassA holds some unmanaged resource that can infact be shared across multiple managed objects, then you should implement some kind of reference counting mechanism. That way when a client of A disposes itself, A will only be disposed when A the client is the last object referencing A.


public class A
{
protected int m_refCount;
// Other code...

private static globalA; // Too expensive to allow many different copies.
public static A GetAnAObject()
{
if (null == globalA)
(
globalA = new A(/*Whatever constructor*/);
}

// We could put in some logic to either create a new object,
// or return an existing one based on the reference count.


globalA.m_refCount++ // increase the reference count.
return globalA
}

public void Dispose()
{
// Decrement the reference count.
if (--m_refCount <= 0)
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
}


All in all it sounds like you just need to employ a couple of simple design patterns.

0. You'll probably need to add a reference counting mechanism for class A. These can be internal to A, or external (via some Factory cleanup method.) But you'll need some mechanism to keep track how many clients have a reference to any one A object. If you only want one A object at any time, then you should look at making A a Singleton.

1. Factory: If A really is expensive to create and copy, but you can have more than one A object in existance, you may want to use an Interface (i.e. interface IA) and Factory pattern to keep a client from just creating A whenever they please. B and C would now reference the interface IA instead of the A object. You could be extra Ninja and make the A class a member class of the AFactory object, so there's no way to create an A object except for when the AFactory class allows it through its public method.

2. If it's just more convenient to be able to share a reference to A for performance reasons (like a Socket or Database Connection) then a Disposable object that has a 'smart' Dispose method like the one I've described will work quite well.

I'm not sure exactly what your constraints are, but I think the above ideas should point you in the right direction. links to the various patterns:

Factory Pattern
Singleton Pattern
Observer Pattern (you might want to look into this one...)
Reference Counted Object (or Smart Pointer)

should be available on Wikipedia or in the Addison Wesley Books
Design Patterns by Gamma et al,
Design Patterns in C# by Steven John & John Metsker

Good luck!

A great "developer-friendly" way of implementing this is having a DestructableObject class which implements all that's needed for Dispose along with a CloseHandle method to close anything that really needs closing:



...And then when you're looking to implement a class which will be holding unmanaged resources, you just derive from DestructableObject and implement CloseHandle in which you'll call whatever function you need to destroy the handle. Good luck!

I think however that the bigger question is whether each class that holds a reference to "Class A" should be responsible for cleaning that up. If your class is truly holding something that *must* be disposed of (usually unmanaged resources), then the code that instantiated that class should be responsible for disposing of it.

compare this to how you would handle a database connection. You might pass the SqlConnection into a bunch of other methods, or set it as a property of another class, but 9 times out of 10, the code that instantiated the class will be the one that calls the Close() method.

Quote:

Original post by Rob Loach A great "developer-friendly" way of implementing this is having a DestructableObject class which implements all that's needed for Dispose along with a CloseHandle method to close anything that really needs closing: *** Source Snippet Removed *** ...And then when you're looking to implement a class which will be holding unmanaged resources, you just derive from DestructableObject and implement CloseHandle in which you'll call whatever function you need to destroy the handle. Good luck!

Or use SafeHandle if you're on .NET 2.0.