Re: Interfaces and abstract classes et al
- From: karl@xxxxxxxxxxxxxxxxxx
- Date: 3 Aug 2006 03:40:32 -0700
I know this may upset some of the more techie C sharp developers, but
would it be fair to say that an interface is fairly pointless if all it
does is outline what a derived class must have in the way of methods
and properties etc?
After all, if these members must be in the derived class anyway, surely
all the interface is doing is telling the developer something he
already knows?
I guess in larger developer environments where many people are working
on one project then they could be usefull as a guideline too to prevent
errors occuring if a member is left out of a derived class.
Do I seem to be on the right track now?
Bruce Wood wrote:
I want to understand the importance of interfaces but dont feel I am
getting the message. If someone could try to explain my worries away
about the differences between interfaces and abstract classes, and
their importance (showing exactly why I must an interface instead of an
abstract class would be nice) I would be most grateful.
Conceptually, the difference between an interface and an abstract class
is the difference between what something *can do* and what *it is*. In
a multiple-inheritance language, this distinction is blurred. However,
in a single-inheritance language, one must be much more careful about
deciding what something is (inheritance), versus what is simply a
capability of that thing, or one thing that it can do (interface).
Let's take the classic animal / dog / cat / bird scenario. An "animal"
is an abstract class. Why? Well, because an animal represents a class
of thing in the real world, but there is no such thing as a "generic
animal": any animal must be of a more specific type. A dog class would
inherit from animal because a dog *is an* animal.
Now, some animals can be taken for a walk. You can certainly walk a
dog. Some people even walk their cats. A bird, however, can't really be
taken for a walk. "Walkability" then, is not what an animal *is*, but
rather something it *can or cannot do*. The other clue is that if you
try to make WalkableAnimal into an abstract class then your class
hierarchy turns into a mess as you try to shoehorn a bunch of animals
that don't really have much to do with each other under the same
abstract base class. So, you define an IWalkable interface that can be
assigned to any animal, regardless of where it falls in the class
hierarchy. Walkable animals may be sprinkled around your class
hierarchy, with some otherwise unrelated animals being walkable, while
between two closely related animals one might be walkable and the other
not.
Again, in a multiple-inheritance language, this distinction between *is
a* and *can do* is often blurred for the sake of expedience: the
ability to share code through inheritance. In Java, C#, and other
single-inheritance languages, you don't have that luxury. You should
use inheritance only when you're sure that B *is a* more specific
example of A. Otherwise, you're dealing with common capabilities, so
use an interface.
.
- Follow-Ups:
- Re: Interfaces and abstract classes et al
- From: Bruce Wood
- Re: Interfaces and abstract classes et al
- References:
- Interfaces and abstract classes et al
- From: karl
- Re: Interfaces and abstract classes et al
- From: Bruce Wood
- Interfaces and abstract classes et al
- Prev by Date: No Backcolor Property for MDI Parent Window
- Next by Date: Re: Interfaces and abstract classes et al
- Previous by thread: Re: Interfaces and abstract classes et al
- Next by thread: Re: Interfaces and abstract classes et al
- Index(es):
Relevant Pages
|
