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?
class myClass
{
string name = "";
public myClass()
{
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.
class myClass
{
SqlConnection con;
public myClass()
{
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
No comments:
Post a Comment