Click here to Skip to main content
15,887,746 members
Please Sign up or sign in to vote.
1.91/5 (4 votes)
See more:
Why C# does not support Multiple Inheritance ? If it the only Diamond problem, then why can't they do something like explicit overriding.
In multiple interface concept we have explicit implementation, then why Microsoft not implemented something similar to that in multiple inheritance.
Posted
Updated 16-Nov-14 17:26pm
v2

It supports only so called "weak form of multiple inheritance": each interface or class can have any number of types in its inheritance least, but the first type listed should be a class, and all other types can only be interfaces. In other words, this is multiple inheritance for interfaces; and each class can implement any number of interfaces but has exactly one base class (except the common root System.Object which does not have a base class).

Why? Multiple inheritance for classes is a very contradictory issue and causes inherent potential design problems. The absence of such inheritance also causes inherent potential design problems. This controversy is one of the inherent problems of OOP technology. This is not just the diamond problem; and this problem cannot be solved with explicit overriding. In fact, overriding is already explicit, so what? If you think there is a solution, you most likely misunderstood this problem. The problem is actually resolved in C++ by using the choice between virtual base and non-virtual. But this feature itself presents an inherent problem. I can explain why. Because this choice itself (between using virtual and non-virtual base) cannot be a matter of late binding. Once you have chosen some class to be a virtual base, it will remain virtual for all other derived classes you may decide to add later.

Unfortunately, it's impossible to explain it in a Quick Answer, but the problems are quite apparent; you will be able to feel them when you face serious OOD problems. Probably, if I had to cover all the aspects of such problems and multiple approached to overcome them (I mean, alternative decisions made in different programming languages, not application problems), I could write a whole book on the topic.

—SA
 
Share this answer
 
v4
Comments
Kornfeld Eliyahu Peter 7-Oct-14 7:22am    
I had no choice but upvote it :-)!!!
Sergey Alexandrovich Kryukov 7-Oct-14 10:58am    
Thank you, Peter.
—SA
[no name] 7-Oct-14 22:02pm    
nice solution
Sergey Alexandrovich Kryukov 7-Oct-14 22:39pm    
Thank you, Sankarsan.
—SA
Sandeep Reddy Badikolu 16-Nov-14 23:28pm    
Great explanation. Loved it
 
Share this answer
 
Multiple inheritance create tight coupling which make maintenance hard.

Thus in any serious application, you want to avoid using multiple inheritance even when it is available like in C++.

For extensibility and reuse purpose, it is better to that your main object contains sub-object. Thus instead of inheriting from say A, B C and D, your object A has sub-object of type B, C and D.

At that point you can easily change a sub-object for a derived one and support a lot of combination.

When it make sense, you might even be able to change a sub-object at run time or decide which sub-object to uses at creation time. This give a lot of flexibility.

One problem with multiple inheritance is that once you use it a lot, you will find that you often have the wrong combination of parent classes and you have a lot of refactoring to adjust the class hierarchy or create similar classes that differs only from one or 2 bases classes among a few one.

Say that you inherited from 3 classes and each of those have 3 subclasses. If you need all possibilities, you will have 4 x 4 x 4 possibilities for parents giving 64 combinations.

On the other hand, if those are sub-object, then you have a single class with 4 possible classes for each sub-object.

Also the parent class would have a lot of unctions and you might have to maintain around 70 to 80 classes if you change one virtual functions.

In the other case, you'll have to change only 4 classes...
 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900