[.net] When should I implement IDisposable?

Started by
5 comments, last by Rob Loach 17 years, 11 months ago
I haven't found a clear article explaining this. So, if I have a class that has members that implement IDisposable, it would be a good idea for the class to implement it and dispose of the members in it's Dispose method, right?
Advertisement
IDisposable is used when the object needs to perform certain tasks when it is destroyed in order to release resources it has acquired. For instance, if you had a class GuyInAPublicBathroom, its Dispose method would flick the indicator back from "occupied" to "vacant". If simply allowing members to be garbage collected is sufficient for cleanup (as is usually the case), there's no need for Dispose.
As you probably know the .NET platform is a managed technology. But sometimes your objects will need control of some unmanaged resources. These resources should be cleaned up as fast as possible. For this you can override the Finalize method, but often it's better to implement the IDisposable interface.

The idea is that the user of the object then sholud call the Dispose method when he's done with the object (i.e. it won't be called automatically).

So, why use the Dispose method instead of the Finalize method? Well instead of waiting for the garbage collector and possibly suffer a performance hit you can via the Dispose method perform the cleanup right away.

A good technique is to make sure that the object will be cleaned for unamanged resources even if the user forgets to call Dispose. So usually you will want to implemetn both the Dispose method as well as Finalize(). In the Dispose method you can then use GC.SuppressFinalize() to make sure you don't try to collect the unmanaged resources twice.

[Edited by - rohde on May 6, 2006 7:53:38 AM]
"We confess our little faults to persuade people that we have no large ones." -Francois de La Rochefoucauld (1613 - 1680). | My blog
Apart from unmanaged resources, if your object has subscribed to events from other types that are either static or has a longer lifetime than your object, make sure you unsubscribe from those events when you're done with your object. If you don't, the events pointing back to the object will keep it alive for a long time, effectively creating a memory leak.
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
IDisposable is good for releasing resources that you are using. Such as files, netowrking, ect. You can get resource leaks just like you get memory leaks.

theTroll
Quote:Original post by TheTroll
IDisposable is good for releasing resources that you are using. Such as files, netowrking, ect. You can get resource leaks just like you get memory leaks.

theTroll


This is generally untrue. Unless the class is using unmanaged resources and only releases them in Dispose (rather than properly implementing the dispose pattern) then the resources will get released eventually, just maybe not as soon as you would like or need.
The using keyword is a nice thing to use to have it call Dispose on objects for you:
string contents;using(TextReader textReader = new StreamReader("MyFile.txt")){    contents = textReader.ReadToEnd()}Console.Write(contents);

Usually you would have to call Close on textReader, but now that we implemented using, it will automatically call Close() and Dispose() on the object for us.

Quote:Original post by mitchw
Unless the class is using unmanaged resources and only releases them in Dispose (rather than properly implementing the dispose pattern) then the resources will get released eventually, just maybe not as soon as you would like or need.
What mitchw says is true.
Rob Loach [Website] [Projects] [Contact]

This topic is closed to new replies.

Advertisement