Java omits multiple inheritance on the grounds that it obviates the design goal of keeping the language simple.
I wonder if Java (with its eco-system) is really "simple". Python is not complex and has multiple inheritance. So without being too subjective, my question is...
What are the typical problem patterns that benefit from a code designed to make heavy use of multiple inheritance
Pros :
Cons :
In C++ a good example of multiple inheritance used to composite orthogonal features is when you use CRTP to, for example, setup a component system for a game.
I've started to write an example but I think a real world example is more worth looking at. Some code of Ogre3D uses multiple inheritance in a nice and very intuitive way. For example, the Mesh class inherit from both Resources and AnimationContainer. Resources expose the interface common to all resources and AnimationContainer expose the interface specific for manipulating a set of animations. They are not related, so it's easy to think about a Mesh as being a resource that in addition can conain a set of animations. Feels natural isn't it?
You can look at other examples in this library, like the way memory allocation is managed in a fined grain way by making classes inherit from variants of a CRTP class overloading new and delete.
As said, the main problems with multiple inheritance rises from mixing related concepts. It makes the language have to set complex implementations (see the way C++ allows to play with the diamond problem...) and the user not being sure what's happening in that implementation. For example, read this article explaining how it is implemented in C++.
Removing it from the language helps avoiding people who don't know how the language is inforced to make things bad. But it forces to think in a way that, sometimes, don't feel natural, even if it's edge cases, it happen more often that you might think.
There is a concept called mixins that is used heavily in more dynamic languages. Multiple inheritance is one way in which mixins can be supported by a language. Mixins are generally used as a way for a class to accumulate different pieces of functionality. Without multiple inheritance, you have to use aggregation / delegation to get mixin type behavior with a class, which is a bit more syntax heavy.
I think the choice is mainly based on issues due to the diamond problem.
Moreover, it is often possible to circumvent the use of multiple inheritance by delegation or other means.
I'm not sure of the meaning of your last question. But if it is "in which cases is multiple inheritance useful?", then in all cases where you would like to have an object A having functionalities of objects B and C, basically.
I won't delve much in here but you can surely understand the multiple inheritance in python via the following link http://docs.python.org/release/1.5.1p1/tut/multiple.html :
The only rule necessary to explain the semantics is the resolution rule used for class attribute references. This is depth-first, left-to-right. Thus, if an attribute is not found in DerivedClassName, it is searched in Base1, then (recursively) in the base classes of Base1, and only if it is not found there, it is searched in Base2, and so on.
...
It is clear that indiscriminate use of multiple inheritance is a maintenance nightmare, given the reliance in Python on conventions to avoid accidental name conflicts. A well-known problem with multiple inheritance is a class derived from two classes that happen to have a common base class. While it is easy enough to figure out what happens in this case (the instance will have a single copy of ``instance variables'' or data attributes used by the common base class), it is not clear that these semantics are in any way useful.
This is just a small paragraph but big enough to clear the doubts I guess.
One place where multiple inheritance would be useful is a situation where a class implements several interfaces, but you would like to have some default functionality built in to each interface. This is useful if most of the classes that implement some interface want to do something the same way, but occasionally you need to do something different. You can have each class with the same implementation, but it makes more sense to push it up into one location.
What are the typical problem patterns that benefit from a code designed to make heavy use of multiple inheritance?
This is just one example but one I find invaluable to improve safety and mitigate temptations to apply cascading changes throughout either callers or subclasses.
Where I've found multiple inheritance incredibly useful even for the most abstract, stateless interfaces is the non-virtual interface idiom (NVI) in C++.
They're not even really abstract base classes so much as interfaces that have just a little bit of implementation to them to enforce the universal aspects of their contracts, as they're not really narrowing the generality of the contract so much as better enforcing it.
Simple example (some might check that a file handle passed in is open or something like that):
// Non-virtual interface (public methods are nonvirtual/final).
// Since these are modeling the concept of "interface", not ABC,
// multiple will often be inherited ("implemented") by a subclass.
class SomeInterface
{
public:
// Pre: x should always be greater than or equal to zero.
void f(int x) /*final*/
{
// Make sure x is actually greater than or equal to zero
// to meet the necessary pre-conditions of this function.
assert(x >= 0);
// Call the overridden function in the subtype.
f_impl(x);
}
protected:
// Overridden by a boatload of subtypes which implement
// this non-virtual interface.
virtual void f_impl(int x) = 0;
};
In this case, maybe f is called by a thousand places in the codebase, while f_impl is overridden by a hundred subclasses.
It would be difficult to do this kind of safety check in all 1000 places that call f or all 100 places that override f_impl.
By just making this entry point to the functionality nonvirtual, it gives me one central place to perform this check. And this check is not reducing the abstraction in the slightest, as it is simply asserting a precondition required to call this function. In a sense, it's arguably strengthening the contract provided by the interface, and relieving the burden of checking the x input to make sure it conforms to valid preconditions in all 100 places that override it.
It's something I wish every language had, and also wished, even in C++, that it was a little more of a native concept (ex: not requiring us to define a separate function to override).
This is extremely useful if you didn't do this assert in advance, and realized you needed it later when some random places in the codebase were encountering negative values being passed to f.
First: multiple copies of base class (a C++ issue) & tight coupling between base and derived classes.
Second: multiple inheritance from abstract interfaces
