> Ok, give a poor C++ programmer a hint... what are we talking about here?
>  <G>

interfaces are another way representing what "multiple inheritance"
(I think poorly) attempts to represent in C++

> Specifically, I've seen many definitions for 'interfaces', but none of
> them seems to quite fit the discussion.  Does some kind soul out there
> feel like enlightening me?

The idea is that OOP is supposed to let you model real world objects.

And you want to be able to treat "similar" objects by identifying
features that unify them (some properties and methods) and then have
your algorithms manipulate them indifferent to further distinctions they
may have.    (Like operating on TControls indifferent to specifics about
each).

In C++ if object "A" is a Widget  then it will have TWidget as a base class.
So you can treat A as if it were a Widget and be indifferent to further
details about it.    And if you restrict to single-inheritance derivations
ALL of the possible ways of looking at "A" need to be represented as
some base class in it's derivation hierarchy.

The problem with this is that real world objects don't come in nice neat
hierarchies - and objects can sometimes be more than one thing.   In C++
if you are faced with adding a whole collection of "new" features into an
existing class hierarchy you either have to add it to some deep base (a
nightmare) or use multiple inheritance (a worse nightmare).

Interfaces get around all this by just admitting the reality that the
world is not arranged in hierarchies.   If something is like a container
then it just is.   To model this with interfaces you expose the "TContainer"
functionality (some properties and methods) and voila you're a container.
If you suddenly have a container that's also a clock - then you also expose
a "TClock" interface and then voila you're a clock too.

Interfaces are kind of like pure virtual abstract base classes in C++.
But if you've ever tried to actually use multiple bases in C++ on
a nontrivial set of classes you know that there are subtle problems with
constructor ordering and other wierdness.    Interfaces don't suffer from
any of this stuff.

I think using interfaces is a deep design decision - and usually
worth doing.

-ns

---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED] 
with body of "unsubscribe delphi"

Reply via email to