|
|
Give me a reason, not related to any language, why multiple inheritance of classes in an object oriented environment is "a bad idea". |
I'm just another guy that tries to make it hard for people to shoot themselves in the foot. |
Note: I don't actually want C++ to change |
Show me why this is a bad idea (assume efficiency and such are not goals). |
Some java programmers people seem to believe that the diamond problem with multiple inheritance cannot be avoided unless support is explicitly stripped from the language. |
What frequently does happen though is that composite-code ends up cluttered with code duplication...effectively cutting off an arm to cure a hang-nail. |
You can inherit from one class, so it would seem to make sense to inherit from more than one class at a time. Indeed you can, but whether it makes sense as part of a design is a subject of continuing debate. One thing is generally agreed upon: You shouldn’t try this until you’ve been programming quite a while and understand the language thoroughly. By that time, you’ll probably realize that no matter how much you think you absolutely must use multiple inheritance, you can almost always get away with single inheritance. Initially, multiple inheritance seems simple enough: You add more classes in the base-class list during inheritance, separated by commas. However, multiple inheritance introduces a number of possibilities for ambiguity, which is why a chapter in Volume 2 is devoted to the subject. |
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”.22 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. |
in Java this problem cannot be solved effectively. You could make Breedable and/or Tameable interfaces, but then you have code duplication from using the same implementation twice, or you would have to place the implementation awkwardly in static methods and call them from the implementing methods. |
rapidcoder wrote: |
---|
That 3DS uses it, ok, Linux kernel uses goto in various places. But that doesn't mean it is good nor we should use it in new programs. |
rapidcoder wrote: |
---|
The implementation for taming and breeding can be placed in nested objects. |
No, it is not. The same design can be done with multiple inheritance of interfaces. No need to inherit classes. |