Why Only 1 Parent in Inheritance?

What's the choice design that microsoft do that? Of course, as of me, I don't use inheritance a lot, or at all.

But just curious.

There may well be other considerations but one I can recall reading a long time ago was the fact that you could end up with name clashes if a class was to inherit like-named members from two or more base classes.

30 seconds searching on MSDN yielded this:

http://blogs.msdn.com/b/dachou/archi...heritance.aspx

Thanks JMCilhinney.

Yea I got the same issue when a class implements 2 different interfaces and those 2 interfaces have the same property. Then one have to shadow the other.

I am just curious.

If we have

Class Rich
End Class
Class Man
End Class
Class Horny
End Class
It seems to make sense to

have Class HornyRichMen inherits Horny, Rich, and Men.

I suppose VB.net classes tend to be more flat in hierarchy than C++ code. Even then in C++ most function are virtuals and you rewrite the code in the derived class. Most feature of inheritance can be replaced with just owning.

So

Class HornyRichMen
Manness as Man
Hornyness as Horny
Wealth as Rich
End Class

Then you run into issue that HornyRichMen cannot be plugged into function that accept Man argument.

But that's where interface iMan, iHorny, and iRich comes in.

There's actually no issue at all when implementing two interfaces with like-named members. When you implement an interface member, there's no requirement for the implementing member to have the same name as the implemented member. This code is perfectly normal:

vb.net Code:

Friend Interface IFirstInterface
    Sub DoSomething()
End Interface
 
 
Friend Interface ISecondInterface
    Sub DoSomething()
End Interface
 
 
Friend Class SomeClass
    Implements IFirstInterface, ISecondInterface
 
    Public Sub DoFirstSomething() Implements IFirstInterface.DoSomething
 
    End Sub
 
    Public Sub DoSecondSomething() Implements ISecondInterface.DoSomething
 
    End Sub
End Class

the Implements clause specifies what interface member is being implemented so the name of the implementing member is can be anything you like. It usually makes sense for the implementing member to have the same name as the implemented member but it's certainly not a requirement.

The main reason is that multiple inheritance makes most programmers' heads explode :)

I see. That makes perfect sense :)

There has been a debate over multiple inheritance for decades. The basic sides are those who feel that it is never a good idea, and those who think there could be some scenario where it does make sense. Of cours, as you have shown, it is always possible to come up with some contrived example where multiple inheritance is the most reasonable answer, but you said yourself that you rarely, if ever, use inheritance of any sort. So how useful would multiple inheritance be in practice? Those who opposed it generally held that it was only useful in making class heirarchies that were so complicated that they were hell to maintain, regardless of how clever they appeared.

In addition to that, they do cause trouble. If class B and C both inherit from class A, and class D inherits both B and C, how many base classes are there? Both the B and C will have base class A members, so which version of the base class members does an instance of D make use of? In C++, this is solved using virtual base classes, but it's a hassle, and never a benefit. An extra layer of complication larded onto the design out of necessity with no clear best practice. Therefore, .NET went with single inheritance and interfaces, which is good enough for 99.99% of the people. In fact, the only ones it is not good enough for are those who work at creating a project specifically so that it can't work effectively without multiple inheritance. We can safely ignore those people.

Yea that diamond is an issue. To be frank, now that inheritance can only be one line, I sort of wonder. What kind of problem need inheritance at all?

I am working on a program that deals with hatcheries. There are various shapes of raceways possible, but they are all raceways. Therefore, I have each shape inheriting from a common Shape object that exposes all the methods. Each specific type has to implement certain features. For instance, each shape has to draw itself. However, since each derived type can be cast to an instance of its base, in the main program I can have:

Private shapes As List (of Shape)

The items in the list could be round, rectangular, or any other shape. Since they all inherit from Shape, they all can be added to the list. I can then iterate through the list calling .Redraw on each of them, and they will redraw in whatever way is specific to that type.

Better yet, the Shape class is defined in one dll, while all of the derived classes are defined in other dlls. That way, I can add new shapes after the fact by just adding another dll that references that base one. The program, when it starts, examines all the dlls to see if they have an instance of a class factory that builds the actual objects as needed....but that's another story. The key is that the main program doesn't even need to know about the existence of any of the derived shape types. All it needs to know is that it has a list of Shape objects, and it works with that. The main program doesn't have references to the dlls that hold the derived shapes, so they act as plug-ins.

So there's an example of using inheritance in the real world.

Quote:

---

Originally Posted by teguh123

Yea that diamond is an issue. To be frank, now that inheritance can only be one line, I sort of wonder. What kind of problem need inheritance at all?

---

You've just got to look at the .NET Framework for your answer. The Component class provides functionality that allows a class to be designed. The Control class extends that by providing UI functionality. The ButtonBase class adds functionality for a control that is intended to be "pressed" like a button. The Button, CheckBox and RadioButton classes all add specific functionality appropriate to their specific use.

Imagine if the Button, CheckBox and RadioButton classes were all built from scratch with no inheritance. There's a whole lot of duplicated code for a start. Also, if you want to change how a button works then you have to do it in all three places.

That's just three classes too. Think about all the other components and controls in the Framework, as well as by third parties, that also inherit the same functionality from the same base classes.

Remeber one of the OO design principles: Favour composition over inheritance.

SH and jmclongname both describe situations that could also be solved with composition. First off, take your "base class" and generate an interface that describes the concept the base class is describing. Next, take your derived class, and don't inherit from the base, but implement the interface instead. Have your "derived" class hold a reference to the "base" class. Implement the interface by delegating all calls to the "base" class instance you have a reference to.

Yes. The thing is you then have to have too many codes whose whole purpose is delegating calls to the pseudo base class. That reminds me again with the idea behind inheritance, not repeating codes.

Then again, the Evil Giraffe way would be the way I do it. Currently I am not using inheritance or interface at all on all of my code and is doing fine.

If I have circle, box, and triangles as shape, I can put an enum on top of it and turn them into a class called shape with no inheritance at all. Circle box and triangles will draw itself based on their enum value.

I guess I'll just read some more.

That sounds like a really bad way of using Enums.

I might have added that about a third of the actual code for any of the classes in my design is in the base class, so that functionality doesn't have to be re-written in the derived classes. Using interfaces, I would have needed to re-create some of that, though it would have been trivial to do.