OOP: About Interfaces 2002-03-23 -- Dennis E. Evans Newsgroups: topspeed.topic.oop
Hi all,
> I have a question about interfaces.
> After reading for a while about them, interfaces seem to be what are called
> "abstract base classes" in C++, except in CW you can't have any member
> variables.
> What they add to Clarion is basically multiple inheritance without the messy
> contructor rules you have in C++.
Abstract base classes are used in the first level or I suppose levels
of a class chain or hierarchy and the base class is never used directly.
A close example in ABC would be the LocatorClass. although a fairly small
class chain. The LocatorClass is never used directly and all the other
locator classes, step, entry ... all derive from the base LocatorClass.
The base class provides a common starting point or base for all the other
classes in the chain, methods and data.
Interfaces where added originally to allow the use of COM a side affect
of interfaces is something of a back door to multi-inheritance. While I
use the term multiple inheritance, when using classes and interfaces it is
not technically correct. You are not really inheriting the interface, not
within the constraints of normal OO inheritance. I guess you could
consider it to be somewhere between inheritance and composition, a little
better than composition but not as clean as inheritance.
One the advantages of interfaces and something like multiple inheritance
is the ability to add classes to a chain only when the specific ability is
needed.
WindowManager class...
cool stuff
end
WindowControlFormat class(WindowManager)
cool control formating
end
WindowColor class(WindowControlFormat)
cool color control for screen control stuff
end
WindowAnotherRealCoolThing class(WindowColor)
end
The problem here is the standard single inheritance chain, if I want the
format class and not the color stuff on a window no problem, I just use the
format class. But what happens when I want the color stuff and not the
format stuff? I can use the color class and ignore the format class but it
is still in the chain and will still be called in the init, kill methods and
probably several others. I can remove the TYPE key word from the higher
level classes and refer to them directly, but that really ends any
usefulness. The problem increases when I want AnotherRealCoolThing but
don't need color or formatting on a window. Now if I do this
StartingWindow class(WindowManager)
MyWindInterface &IWind
AddInterface procedure(Iwind w)
end
Iwind interface
very cool methods
end
WindowControlFormat class,implements(Iwind)
end
WindowColor class,implements(Iwind)
end
and so on
I can now add one or all the classes to the StartingWindow and only the
ones I add are there, they can also be removed at run time but that seldom
provides much benefit. I sometimes think of it as 'plugging in' an
interface, not an accurate CS term but it works.
Not really inheritance there are some benefits. I can do pretty much what
I want in the WindowFormat class and not impact the others, they can only
access the WindowFormat through the Iwind. The is a small problem with
this, the classes have different properties and you need to manipulate those
properties from the WindowStart class and the WindowStart class has no idea
the data exists. There are ways to handle that with some derived interfaces.
The other problem is the Clarion IDE, it is no where sophisticated enough to
even begin to deal with this so you have to use source code, not really a
problem I guess but inconvenient.
Actually the longer I use interfaces in this manner I sometimes think they
are a better solution than multiple inheritance. Multiple inheritance can
get real ugly real fast but like all things it has a place.
Dennis
"It is practically impossible to teach good programming style to students
that [sic] have had prior exposure to BASIC; as potential programmers they
are mentally mutilated beyond hope of regeneration."
Dijkstra
Printed May 5, 2024, 12:57 pm This article has been viewed/printed 35121 times. Google search has resulted in 13 hits on this article since January 25, 2004. |