Multiple inheritance is not supported in dotnet. But multiple interface supports?

Question

Multiple inheritance is not supported in dotnet. But multiple interface supports. Why this kind of behaviour exists. Any specific reasons??

Answer 1

In general, multiple inheritance creates more problems than it solves. Think about how virtual method calls have to be resolved. What if a class doesn't define a method but both of its parents do? Which one should execute?

Implementing multiple interfaces, however, has no such problems. If two interfaces define the same method and you actually try to implement them, your code won't even compile (although I'm unsure if you could explicitly implement them and satisfy the compiler requirements).

Answer 2

The danger with multiple inheritance of concrete classes is that there is storage and virtual method lookup that must be reconciled between the two or more parents of a given class. Especially tricky is when there are shared ancestors. But interfaces only define what a class should look like, not how it needs to be implemented and it's much easier to make a class look like a lot of different things than it is to make it be a lot of different things. Two interfaces can require a method int Foo() and an implementing class can safely use both interfaces and implement Foo() without causing headaches for which base Foo() to override, etc.

Another reason is that constructor chaining is difficult to manage with multiple inheritance. But interfaces don't specify constructors, so that problem is entirely sidestepped.

There are certainly many other reasons why multiple inheritance is bad.

Answer 3

You can simulate multiple inheritance using interfaces. If multiple inheritance with classes were allowed, it would lead to the Diamond problem.
For reasons multiple inheritance is not supported, I suggest you read Why doesn't C# support multiple inheritance?

Different languages actually have different expectations for how MI works. For example, how conflicts are resolved and whether duplicate bases are merged or redundant. Before we can implement MI in the CLR, we have to do a survey of all the languages, figure out the common concepts, and decide how to express them in a language-neutral manner. We would also have to decide whether MI belongs in the CLS and what this would mean for languages that don't want this concept (presumably VB.NET, for example). Of course, that's the business we are in as a common language runtime, but we haven't got around to doing it for MI yet.

The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation. If we were to add a slightly different construct, like mixins, would that actually be more powerful?

Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places.

Answer 4

Because interfaces do not the implementation details, they only know what operations an object can do. Multiple inheritance is difficult when there are two different implementations are found for the method with same signature in both the base classes. But in case of interface both the interface may define a common method with same signature but they are not implemented at the interface level, they are only implemented by the object or type that implement both the interfaces. Here though there are two different interfaces defining two methods with same signatures, the object provides the common implementation satisfying both the methods in both the interfaces. So there is no ambiguity between implementations, both the methods have common implementation hence you could have multiple inheritance in case of interfaces.