Sign in to follow this  
tnutty

Your thoughts about MI

Recommended Posts

I just noticed that multiple inheritance get very complicated. Is it worth using? I would think one should use a moderate amount and limit himself. Like so :
class A
{
  public :  int a_int;
  A() : a_int(0) { }
  A(int a) a_int(a) { }
};

class B : public A
{
  //implementation omitted
  
};

class C : public A, protected B
{
   //implementation omitted
};
class D : virtual public A, protected C
{
  //omitted
};
class E:
{
  public :  int a_int;
  E() : a_int(0) { }
  E(int a) : a_int(a) {  }
};
class F : public B, virtual public E
{
  //omitted
}


Although some of these might be redundant its just to prove a point. As you can see it gets really complicated fast. Its hard to keep track sometimes. I have read that some people love it while others hate it. Whats your thoughts from your experiences?

Share this post


Link to post
Share on other sites
Any inheritance (multiple or single) should only be used if you're expressing the OO concept of "is a" -- otherwise, the tool you want to use is composition (i.e. member variables).

In my experience, the most common form of MI is the "Java style" of abstract interfaces:
class IFoo {
public:
virtual void Foo() = 0;
};
class IBar {
public:
virtual void Bar() = 0;
};
class Base {
public:
Base();
virtual ~Base();
};

class Derived : public Base, public IFoo, public IBar
{
public:
Derived();
virtual void Foo();
virtual void Bar();
}


Usually interfaces such as IFoo/IBar don't need virtual inheritance, but if you're coding a dreaded-diamond for whatever reason, then you'll need it.

In most cases where private/protected inheritance is used, composition can/should probably be used instead.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hodgman
Any inheritance (multiple or single) should only be used if you're expressing the OO concept of "is a" -- otherwise, the tool you want to use is composition (i.e. member variables).

In my experience, the most common form of MI is the "Java style" of abstract interfaces:*** Source Snippet Removed ***


So your saying using containment is better than private or protected derived
class? What about when one needs to access protected members from a base class?

Share this post


Link to post
Share on other sites
Quote:
Original post by tnutty
So your saying using containment is better than private or protected derived
class?
Yes, if your derived class cannot be used in-place of it's base type, then inheritance is wrong.

Private/protected inheritance is a special case of this though, because it expresses "is a" while never allowing derived to be used as a base... so it isn't really inheritance -- it's just composition disguised as inheritance.

Quote:
What about when one needs to access protected members from a base class?
Protected members are actually part of the "public-interface" of a class, because the details of their implementation are not hidden from the users of the class.
If these members need to be directly modified by other (unrelated) objects, then why not make them public?

Share this post


Link to post
Share on other sites
As Hodgman notes, inheritance itself tends to be overused.

Multiple inheritance as it exists in C++ is mostly broken and not worth the effort. In most any type system, it's mostly broken and not worth the effort. That said, I think that is a useful tool for accurately modeling objects in type systems where it's implementation does not resemble the fires of hell.

Share this post


Link to post
Share on other sites
You should always use the most appropriate tool for the job, and multiple inheritance is no exception to this. It's just that the range of jobs where MI is the appropriate tool is a fairly small one because composition, singular inheritance and templates/ad-hoc polymorphism are usually much better suited. If you end up dealing with the dreaded-diamond and virtual inheritance then, IMO, you've done something wrong.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this