The Power of Multiple Inheritance
- From: "John" <John@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 24 Apr 2005 23:39:07 -0700
I find it sad that many .NET framework developers and Java developers chant
the mantra, "multiple inheritance is bad... multiple inheritance is bad..."
while happily implementing away multiple interfaces in their classes and
raving about the power of being able to apply combinational patterns to
composite multiple interfaces into a whole. This is a form of multiple
inheritance!
The pitfalls with multiple inheritance come when the base classes become too
complex. Sun had the right idea when they dumbed down multiple inheritance to
the point where only stateless, interfaces devoid of any logic could be
multiply inherited. The problem was that they dumbed it down too much.
Why exclude state variables, for instance? Take the interface for a text
control (ITextControl, if you like). The shared component of all classes that
implement this interface should be a text property, but no class would
implement this text property without an associated string variable storing
this state. Why require this redundancy from programmers that implement this
interface?
Further, I would bet that 99.9% of the classes that implement such an
interface will have the same redundant code for the read portion of the
property, and that will simply be to return the current state of the text
(just returning the value of the associated variable). Any programmer who
knows anything about good software engineering standards should know that
this kind of redundancy is the prime characteristic of poor, unreusable
design. The default, un-overridden behavior of such a text control base
should be to return the associated state variable when reading from the
property and to change this associated state variable and notify the host
(the class that derives the text control base) of this change. This default
behavior should satisfy the design of 99.9% of the classes that composite
this text control base into their design, with the only requirement for
working the text control into their design is that they implement the
callback for when the property is modified (this should usually just be a
matter of redrawing the control on the text change).
Now, take a look at the .NET framework library or the Java library and you
can see the unforeseen pain that resulted from dumbing down multiple
inheritance to nothing but interfaces. Look at the scrollbar GUI classes, for
instance (HScrollBar and VScrollBar in .NET). They have a Text property that
they derive from Control. Why do they have a Text property when it is
absolutely useless for a scroll bar? I'll tell you why. The developers of the
..NET framework ran into the same issues of having to deal with a lot of
redundant code by implementing multiple interfaces to compose new controls,
so they figured it would be far more manageable to create a real, gigantic
base class called Control that would encompass the needed base functionality
and state variables of all the controls whether they're scroll bars or text
boxes or whatever rather than separating these aspects into multiple control
interaces that could be multiply inherited as necessary. This means having a
bunch of unused functions, state variables, and properties in each control.
However, they decided they could hide up this obfuscation by putting in IDE
hints to filter them out from intellisense and the property editor.
I would agree that their solution was the best they could do under the
limitations of .NET. However, making an overly complex base class that has
unneeded functionality that is simply filtered out through the IDE is far
from an elegant design solution if you ask me. Aside from being wasteful
(though this waste is worse in principle than in reality, where it is
probably trivial on most of today's machines running on a gig or two of RAM),
it is horribly unmanageable compared to the elegant alternatives provided
through skilled use of multiple inheritance. I shudder to think of how the
code looks like for the Control base. Still, it's obvious that Microsoft had
the money and manpower to deal with this unnecessary complexity as the .NET
framework does work well, but not all of us have the resources to throw a lot
of money and manpower into an unmanageable project. There are some major
design limitations that accompany the lack of sophisticated multiple
inheritance, and it saddens me to think of how much more elegant the .NET
framework could have been had it not been for these language limitations.
- John
.
- Prev by Date: Why can't I use CreateProcessWithLogonW() in VC++ .NET?
- Next by Date: Assembly reference in VS 2003
- Previous by thread: Why can't I use CreateProcessWithLogonW() in VC++ .NET?
- Next by thread: Assembly reference in VS 2003
- Index(es):
Relevant Pages
|
