Hi jm,
here is a good example, keep reading the first paragraph then you will get
to the bit where interfaces are useful, I could give you a textbook example,
but here is one example that is useful in everyday C# life. With C# you have
garbage collection which is non deterministic, meaning once your objects go
out of scope you cannot say exactly when their underlying resources are going
to be cleaned up, it is up to the garbage collector to decide when this will
happen. This is normally not an issue but when your objects have references
to unmanaged resources such as network connections / database connections /
unmanaged memory allocations etc you want to be able to control that these
resources are cleaned up as soon as you are finished using the object, since
the GC is not aware that these resources are limited and will not know it
should clean up the object ASAP.
..Net has an interface called IDisposable which has a single method "void
Dispose()". The idea being that when this method is called all internal
state is cleaned up, so you can control exactly when network connections / db
conn etc are closed. Now what it means for two different objects to "clean
up" their internal state can be completely different, these objects do not
share any common cleanup code so it makes no sence to make them inherit from
some base class just so they both have the Dispose method, objects that
implement IDisposable can define how objects can be cleaned up inside the
Dispose method, so in code you end up with:
void MyFunction()
{
MyDatabaseObjec t db = null;
MyCustomMemoryC reator mc = null;
try
{
db = new MyDatabaseObjec t();
mc = new MyCustomMemoryA llocator();
//do some stuff
}
finally
{
//going out of scope, lets release all unmanaged state
//this is inside the finally since we want to make sure these resources
//are cleaned up even if there is an exception in the function.
if(db != null) db.Dispose();
if(mc != null) mc.Dispose();
}
}
It's kind of a pain to have to use the try / finally each time so you can
use the "using" keyword which takes an object that implements the IDisposable
interface, the objects passed to this language construct may not be related
at all, all this construct knows is that on each object it can call a method
called Dispose() once the current scope of the using statement is exited.
//The following code is semantically equivalent to the above code:
using(MyDatabas eObject db = new MyDatabaseObjec t())
using(MyCustomM emoryCreator mc = new MyCustomMemoryC reator())
{
//do some work
//Dispose method on each object will automatically get called.
}
So you can see how even though you have objects that need to implement the
same interface i.e. a Dispose method, they may have nothing in common so you
do not want those objects to inherit from a base class since they share NO
common code just a common interface.
Kind of long winded but a good example of why interfaces are useful :-)
Mark.
--
http://www.markdawson.org
"jm" wrote:
I am having trouble understanding the purposes of an interface, even
though the concept of interfaces is around me all the time (user
interface, for example). I'm just not understanding software
interfaces.
Like anything else, it appears Interfaces are by design something that
requires documentation. I know this may be obvious, but if I have a
class A and I say, well, class A implements IMyInterface. The fact
that it implements IMyInterface is supposed to mean something to me. I
am guessing that MS and other Sun have a lot of well defined and
documented interfaces that I would eventually care about.
I guess I am looking for a time when their absence would require them.
I think that by seeing their missing from a given situation that
requires them (or would be hard without them), I might see and
understand their necessity and understand.
Does anyone have an example of this? I hope this made some sense.
Thank you.
