The
reason MI exists in C++ and not in other OOP languages is that C++ is a hybrid
language and couldn’t enforce a single monolithic class hierarchy the way
Smalltalk does. Instead, C++ allows many inheritance trees to be formed, so
sometimes you may need to combine the interfaces from two or more trees into a
new class.
If
no “diamonds” appear in your class hierarchy, MI is fairly simple
(although identical function signatures in base classes must be resolved). If a
diamond appears, then you must deal with the problems of duplicate subobjects
by introducing virtual base classes. This not only adds confusion, but the
underlying representation becomes more complex and less efficient.
Multiple
inheritance has been called the “goto of the 90’s”.
[67]
This seems appropriate because, like a goto, MI is best avoided in normal
programming, but can occasionally be very useful. It’s a
“minor” but more advanced feature of C++, designed to solve
problems that arise in special situations. If you find yourself using it often,
you may want to take a look at your reasoning. A good Occam’s Razor is to
ask, “Must I upcast to all of the base classes?” If not, your life
will be easier if you embed instances of all the classes you
don’t
need to upcast to.