[comp.lang.c++] How to use Inheritance instead of n

johnson@m.cs.uiuc.edu (07/23/90)

heintze@mcsse.enet.dec.com.UUCP writes:
>I wanted to nest some classes inside of classes on Zortech C++ v2.01 and
>found out that this cannot  be done like it can for pascal records. I ended
>up using pointers to the (sub)classes.    Hmmph...   Upon driving to
>work this morning it  dawned on me that this is what inheritance is for!

Several people described how to solve this problem using multiple
inheritance.  Nobody seemed to mention that you don't need multiple
inheritance to solve it, and that C++ actually does let you "nest
classes inside of classes".

First, I would like to correct terminology.  C++ does not represent
classes at run-time (except for v-tables) so I quickly figured out that
all uses of "class" in the first paragraph should be replaced by "object".
It is pretty common to confuse classes and objects, but I don't want to
let this pass, because it is important to distinguish between classes
(types) and objects (values).

Suppose you have a class A, and you want to define a new class B that
contains several instances of A.

class B {
  A oneA, secondA, thirdA;
}

is all you have to do.  Thus, a B contains several A's as components.

The major problem is when the constructor of A has arguments, because
then you have to pass them to the constructor of B.  I don't know how
many of the C++ books describe how to do this.  I know that Stroustrup
does, and I assume that most of them do, though it is a feature of C++
that isn't used heavily, so some books might ignore it.  Actually, I
imagine that you have to use the same trick inheriting multiple
constructors.

My own opinion is that inheritance is the wrong technique to use in
most of these cases.  For example, in Smalltalk, Semaphore is a subclass
of List and Process is a subclass of Link, because there is a list of
Processes waiting on each Semaphore, and each Process can only be on
one list.  Although I usually like the design of the Smalltalk class
library, I think that this is pretty wierd.  The fact that Processes
can be put on lists is part of their implementation, not their specification.
Normal users should never know that Processes have links inside them.  Thus,
inheritance is the wrong way to reuse the code for Lists and Links.

In general, multiple inheritance is almost never needed.  I have never
seen a published example of a C++ program using multiple inheritance
that couldn't be coded just as easily using components instead.  (This
is not true for some other systems, such as flavors.)  Sometimes multiple
inheritance is the best way to think of a problem, but it is grossly misused
in the C++ world.  I would be happy for people to point me to examples of
multiple inheritance in which it is obviously better than any of the
design alternatives.

Ralph Johnson -- University of Illinois at Urbana-Champaign