Jump to content
  • Advertisement
Sign in to follow this  
GDKnight

[.net] C# Eliminated Multiple Inheritance?

This topic is 4699 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was wondering if anyone could explain to me the reason that Microsoft removed multiple inhertiance for C#, you can emulate it using interfaces but that is not exactly the same. Does anyone know why they choose to eliminate it?

Share this post


Link to post
Share on other sites
Advertisement
It's not so much that they eliminated it, as that they didn't implement it in C#.

Share this post


Link to post
Share on other sites
You can create multiple interfaces and then inherit a class from as many interfaces as you want. But you can only inherit from one class. This design scheme forces a downward tree of class structure.

Share this post


Link to post
Share on other sites
Multiple inheritance in C++ is one of the most contentious points of use in the language. There are many accademics who view it as somewhat of a broken pattern, though I suspect that that has more to do with how C++ chose to impliment it, rather than the thought of MI itself. Many other languages also eschew MI as well, both Java and the language D are examples.

Also, C# is not really meant to be so much of a "better C++" as it is its own entity. It looks similar on the surface for sake of familiarity, but its design goals and philosophies have little to do with those of C++.

Share this post


Link to post
Share on other sites
Counter question: can you give me an example as to when you would use multiple inheritance in a "real world" application?

With the ability to implement multiple interfaces I've never even dreamed of using multiple inheritance in the five years I've been working with it.

Share this post


Link to post
Share on other sites
There are good reasons for MI. I use MI a few times in my engine where my material system (which is in a dll) is derived from both the material system interface (IMaterialSystem) and a singleton class since it doesn't make sense to have more than one material system going. So the declaration looks like this:

class MaterialSystem : public Singleton< MaterialSystem >, public IMaterialSystem
{
...
};

Another use could be you have a class that represents some type of object and it is derived from both Renderable and ShadowCaster. So this object is to be rendered and will cast shadows but it's possible you want an object that's renderable but doesn't cast a shadow. It would not be a good idea to have ShadowCaster derive from Renderable (or the other way around, whatever) b/c doing that, while may reduce to SI, you may not want every object that's renderable to cast shadows. Or instead of ShadowCaster maybe you have MoveableObject. Or maybe you want all three!

The OGRE engine is a good example of using MI which does so reasonably.


-SirKnight

Share this post


Link to post
Share on other sites

The difference lies in these relationships:
On one hand you have the "IS-A" relationship, on the other the "HAS-A" or "CAN". These are very different relationships, and your design should reflect these differences.

A dog IS an animal, and it CAN bark

class Dog : Animal, IBarkable

An other fact is that MI can lead to ambiguous function calls, for example when you have class A derive from B and C, which both implement a virtual function Func().

Now when you call A.Func(), which one will be called?

I honestly believe that you can implement any system with SI, and it will come out cleaner.

Just my 2 cents,

Edo

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by SirKnight

Another use could be you have a class that represents some type of object and it is derived from both Renderable and ShadowCaster. So this object is to be rendered and will cast shadows but it's possible you want an object that's renderable but doesn't cast a shadow. It would not be a good idea to have ShadowCaster derive from Renderable (or the other way around, whatever) b/c doing that, while may reduce to SI, you may not want every object that's renderable to cast shadows. Or instead of ShadowCaster maybe you have MoveableObject. Or maybe you want all three!
-SirKnight



Renderable is an Interface. Classes in C# can implement multiple interfaces. So this is not really a problem. In your example your class which doesn't casts shadows doenst't derives from Shadowcaster. It just implements the Renderable Interface.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by SirKnight

Another use could be you have a class that represents some type of object and it is derived from both Renderable and ShadowCaster. So this object is to be rendered and will cast shadows but it's possible you want an object that's renderable but doesn't cast a shadow. It would not be a good idea to have ShadowCaster derive from Renderable (or the other way around, whatever) b/c doing that, while may reduce to SI, you may not want every object that's renderable to cast shadows. Or instead of ShadowCaster maybe you have MoveableObject. Or maybe you want all three!
-SirKnight



Renderable is an Interface. Classes in C# can implement multiple interfaces. So this is not really a problem. In your example your class which doesn't casts shadows doenst't derives from Shadowcaster. It just implements the Renderable Interface.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!