Re: Why C++ Is Not ???Back???

BGB <cr88192@hotmail.com> wrote:


Multiple inheritance is actually much, much more prevalent than people
seem to think.

For some reason a good majority of programmers and programming languages
seem to think that so-called "interfaces" are something distinct from
multiple inheritance. As if a language had interfaces *instead* of MI.

That makes no sense. Multiple inheritance is the exact same thing as
regular inheritance, with the only difference being that you are
inheriting from more than one base class. In a proper inheritance
hierarchy there's always a "is-a" relationship between derived class
and base class. The base class being an "interface" does not change this
fact at all.

For example, let's say that you have a base class named "Widget" and an
interface named "EventListener". You now inherit a class named "Button"
from Widget and EventListener. Now your class Button "is-a" Widget, and
"is-a" EventListener. It follows perfectly the principles of object
oriented design and inheritance. Wherever an object of type Widget is
expected you can give an object of type Button. Wherever an object of
type EventListener is expected you can give an object of type Button.
That's what inheritance is.

Therefore the class Button above uses multiple inheritance: It has an
"is-a" relationship with more than one other class. That's the very
definition of multiple inheritance.

The more relevant question is, however, whether the full MI offered by
C++ have any advantages over the crippled MI offered by the majority of
other OO languages? And the answer is yes.

The most prominent advantage is that you can provide default implementations
for some or all of the functions in your "interface" class. This lessens
the need for code repetition and helps making reusable code. It also
burdens the derived class less because it doesn't force it to implement
things that could very well be implemented in the interface.

A very practical use of this is to have *optional* functions in your
"interface" class. In other words, functions that the derived class can
override but doesn't have to. The default implementation could be empty
or return a default value.

(Some other OO languages, such as Objective-C, have the concept of
optional functions in an interface (or protocol, as Obj-C calls it),
but you can't have them return any default values, and such optional
functions burden the implementation of whatever uses objects that
implement that interface because it has to explicitly check if the
object is implementing that precise function. Even though the function
may be optional, the interface cannot have a default implementation for it.)

And if a function in an interface can have a default implementation,
then it's also useful if the interface could also provide some member
variables that those default implementations could use for their work.

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---