Multiple inheritance
-
why Interface supports multiple inheritance ? & why abstract class don't?what is the reason?
It was a decision taken in the original design on C#. Multiple inheritance is deemed to complex, without enough benefits. Inheritance is often described as an "is-a" relationship. I.e. a Car is-a vehicle so the car class inherits from vehicle. Usually, when people try and do things with multiple inheritance, what they are doing is forming a "has-a" relationship, which would be better represented as a class that contains the other class, rather than inherits from it. There aren't many cases where you have an object that is two separate types of sub objects. A Car is-a vehicle and a car also is-a ManMadeItem, but this forms a hierarchy (Car->Vehicle-ManMadeItem) so multiple inheritance isn't needed. If you look at your design, I think you'll find in almost all cases where you have multiple inheritance you can either change it to a hierarchy or a composition instead. Even in languages that support it, it is general discouraged. http://en.wikipedia.org/wiki/Multiple_inheritance#Criticisms[^]. There's an article here[^] about a possible way to achieve it in C#, but I don't recommend it for anything beyond academic interest.
Simon
-
why Interface supports multiple inheritance ? & why abstract class don't?what is the reason?
-
why Interface supports multiple inheritance ? & why abstract class don't?what is the reason?
waqarnaeem2@hotmail.com wrote:
why Interface supports multiple inheritance ?
It doesn't. Interfaces define an implementation contract. You don't inherit anything from an interface, it just forces you to implement the interface.
Man who stand on hill with mouth open wait long time for roast duck to drop in
-
It was a decision taken in the original design on C#. Multiple inheritance is deemed to complex, without enough benefits. Inheritance is often described as an "is-a" relationship. I.e. a Car is-a vehicle so the car class inherits from vehicle. Usually, when people try and do things with multiple inheritance, what they are doing is forming a "has-a" relationship, which would be better represented as a class that contains the other class, rather than inherits from it. There aren't many cases where you have an object that is two separate types of sub objects. A Car is-a vehicle and a car also is-a ManMadeItem, but this forms a hierarchy (Car->Vehicle-ManMadeItem) so multiple inheritance isn't needed. If you look at your design, I think you'll find in almost all cases where you have multiple inheritance you can either change it to a hierarchy or a composition instead. Even in languages that support it, it is general discouraged. http://en.wikipedia.org/wiki/Multiple_inheritance#Criticisms[^]. There's an article here[^] about a possible way to achieve it in C#, but I don't recommend it for anything beyond academic interest.
Simon
Simon Stevens wrote:
A Car is-a vehicle and a car also is-a ManMadeItem, but this forms a hierarchy (Car->Vehicle-ManMadeItem) so multiple inheritance isn't needed
I don't think I'd regard that as a hierarchy, because a horse could also be regarded as a Vehicle even though it is not a ManMadeItem. I think the simplest way to look at the issues of inheritance versus interface is that an inherited base class can supply default fields and methods which are then usable by child classes; an interface not only does not provide default storage for fields and code for methods, but it can't even bind them by default. If an object inherited from Class1 and Class2, both of which provided a Smile method, it would be unclear whether TheObject.Smile was supposed invoke Class1.Smile or Class2.Smile. With interfaces, however, there is no problem. TheObject must have an "implements" line for every interface method it supports, indicating what method should be used for Interface1.Smile and which one should be used for Interface2.Smile. Further, to actually use either of those methods on an object, the object must first be cast to Interface1 or Interface2. Thus, there is no ambiguity.