Ant wrote:
Hi,
I’m wondering what practical use is there for creating interfaces. I can
fully appreciate creating an abstract class for the purpose of inheriting,
but why an interface? Is it just to promote polymorphism while keeping
implementation unique? I dunno; I know I must be missing something big here.
Any clues would, as always, be greatly appreciated.
Thank you
Ant
Ant wrote: Hi,
I’m wondering what practical use is there for creating interfaces. I can
fully appreciate creating an abstract class for the purpose of
inheriting, but why an interface? Is it just to promote polymorphism while keeping
implementation unique? I dunno; I know I must be missing something
big here. Any clues would, as always, be greatly appreciated.
Thank you
Ant
The purpose of an interface is to specify for a class that it "adheres
to a contract", or put simply, it implements a specific set of
functionality.
Let me describe an example.
Let's say you have a lot of visual controls that you use in your
WinForms applications. These inherit from normal .NET runtime visual
controls, and thus, by necessity, inherit from a lot of different classes.
If you now wanted to add a specific function to all of your own visual
controls so that you could loop through all the controls on a form and
say something like this:
if (IsMyControl(control))
control.DoSomethingSpecificForMyControls();
then you would have to do the following:
1. Implement DoSomethingSpecificForMyControls in all of your controls
(of course)
2. The above if-statement would have to be written like this:
if (control is MyButtonType)
((MyButtonType)control).DoSomethingSpecificForMyCo ntrols();
elseif (control is MyTextBoxType)
((MyTextBoxType)control).DoSomethingSpecificForMyC ontrols();
elseif ...
and so on. Since you can't change the base class (because it's in the
runtime and thus out of your control, and it's also a lot of different
base classes in this case), you can't really do anything but lift the
method up to the first point where you have access, in your own classes.
The problem of using these controls now becomes twofold:
1. You can't easily detect wether a class is one of your own (or rather,
that it implements that specific function you need) without listing up
all the class types you know of, or using RTTI and seeing if that
specific method name is present.
2. You can't easily call that method without either casting the object
to a specific class (which differs for each) or by going through RTTI to
invoke it dynamically.
Listing all the classes is certainly doable, but the problem becomes
maintenance. The second you add a new visual control you need to go back
and find all those lists and add the new one with the appropriate code.
Looking for the method name is a kludge, but again doable, if the method
name is reasonably obscure such that you can assume nobody else would
ever want to add such a method. If your method name is "Load" or
similar, you might have problems.
So, enter interfaces. An interface is a way to do the following:
1. Tag a class as "this class supports functionality XYZ"
2. Easily typecast the class to a specific interface so that you can
call the method(s)
In other words, the above if-statement becomes:
if (control is IMyControl)
((IMyControl)control).DoSomethingSpecificForMyCont rols();
That's it. Any new classes you write only need to implement that
interface and all existing code that already knows how to deal with it
will be able to handle it.
Think of your classes as a cube. When you deal with the class directly
you are looking at one side of the cube. When you need to deal with the
class in a different way, you turn the cube to find a side with the
buttons you need to use. As long as you know how to use a specific side
of the cube that contains the functions you know about, you don't need
to care about what the other sides of the cube contains.
This is also the reason why a lot of things in libraries are best left
to interfaces, so that method parameters use the interface types instead
of a specific class type, locking you into inheriting from a common base
class. If the method in the runtime uses an interface, you can implement
that interface in your own classes (regardless of what they inherit
from) and pass objects of that type to that method, and it'll work.
I hope this become clearer now, otherwise just let me know what is still
unclear and I or someone else will probably clear it up.
--
Lasse Vågsæther Karlsen
http://www.vkarlsen.no/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2
