Implementation of IDisposible is confusing a bit. Do w rally need anything special to clean up memory ? In most cases no need to implement in .NET environment. CLR will take care on behalf of you. But It’s really needed when you are dealing with unmanaged resources like File scream, Database connection ,COM component etc.
Here is very simple check to know whether I should implement something to manager my resource in class or not.
1) Is the class is using any unmanaged object ?
2) Is the class is using any managed (IDisposible) object?
I know the first point is very clear but second point may not ! ok. The second point is saying that , If you use any object which is using IDisposible interface in your class then we will consider this as managed object and will implement something to manage the managed object.
Let’s have a look on example. Do we really need to implement IDisposible in this class?
string name = "";
name = "Sourav Kayal";
No, because we are handling “string” class here and which is managed by CLR. Here is stricture of string class.
public sealed class String : IComparable, ICloneable, IConvertible, IComparable<string>, IEnumerable<char>, IEnumerable, IEquatable<string>
None of the interface is derived from IDisposible interface. Now, let’s modify our class little.
con = new SqlConnection();
If we check structure of SqlConnection class.
public sealed class SqlConnection : DbConnection, ICloneable
we will see that it has derived from DbConnection and ICloneble and structure of DbConnection is like this.
public abstract class DbConnection : Component, IDbConnection, IDisposable
We are seeing that it has implemented IDisposible to dispose connection object. So, If we apply idea from Point 2. SqlConnection class is using IDisposible (because parent class uses it)and we will consider SqlConnection object as managed object and we have to implement some mechanism to manage connection object.
Now, the question is ! how we can manage connection object ? Using destructor ? Ok, Destructor or Finalizer is a way to clean up resource but that is not in our hand. This is something like that “ You are prepared your house to serve your guests but don’t know when guest will come !! J “
Here is few points as per my Idea, why Destructor might be fallback mechanism but not primary one.
1) They do not run on your thread; they run on their own thread. That may cause deadlocks!
2) An unhandled exception thrown from a destructor is bad news. It is on its own thread; who is going to catch it?
3) A destructor may be called on an object after the constructor starts but before the constructor finishes. A properly written destructor will not rely on invariants established in the constructor.
4) A destructor might never run; you can't rely on the object ever being scheduled for finalization. It probably will be, but that is not a guarantee.
A obvious better choice is to implement IDisposible pattern. If you implement so, the steering of Garbage collector is in your Hand. J