Can inheritance be replaced completely by composition?

Question

This question is NOT question like \"inheritence vs composition\".

I understand completely how inheritance differs from composition, I know the Lisk

Answer 1

The Short Answer

It's really not as black and white as that. In short, yes. Any situation that can be solved with inheritance can be solved, near enough, by composition. So in short, the answer to your question is yes; inheritance can be replaced by composition.

Why it's not that simple

When to use Inheritance
It's not a matter of whether you CAN swap them out. It depends on the context that you're programming in, and it becomes more of a question of whether you SHOULD swap them out. Take this simple example in Java:

public class Person
{
    // Assume every person can speak.
    public void speak()
    {
    }
}

Now, let's say we have another class, Dave. Dave IS a person.

public class Dave extends Person
{
     public void speak() { System.out.println("Hello!"); }
     public void killSomeone() {} // Dave is a violent Guy.
}

Now would it make more sense for the class Dave to look like this?

public class Dave
{
     private Person p;
     // Composition variant.

     public void speak() { p.speak(); }
     public void killSomeone() {} // Dave is a violent Guy.
}

This code implies Dave has a person. It's not as simple and doesn't explain itself as well. Also, anything a Person can do, Dave can do, so it makes sense that we assert Dave is a "Person".

When to use Composition

We use Composition when we only want to expose part of the class' interface. Following our previous example, let's say Dave has a Guitar. The guitar has a more complex interface:

public class Guitar
{
     public Color color;
     // Guitar's color.
     public Tuning tuning;
     // Guitar's tuning.

     public void tuneGuitar()
     {}

     public void playChord()
     {}

     public void setColor()
     {}
}

Now, if we were to inherit this class, what would the outcome be?

Well, class Dave would now have attributes color and tuning. Does Dave have a tuning? I think not! This is where inheritance makes no sense. We don't want to expose the entire Guitar interface along with the Dave interface. We only want the user to be able to access what Dave needs to access, so in this case we would use some composition:

public class Dave extends Person
{
     private Guitar guitar;
     // Hide the guitar object. Then limit what the user can do with it.

     public void changeGuitarColor(Color newColor)
     {
         // So this code makes a lot more sense than if we had used inheritance.
         guitar.setColor(newColor);
     }


     public void speak() { System.out.println("Hello!"); }
     public void killSomeone() {} // Dave is a violent Guy.
}

Conclusion

It's really not a case of what can replace the other. It's about the situation that you are implementing the techniques in. Hopefully, by the end of the example you'll see that inheritance is for situations where one object IS A object, and composition is used when one object HAS A object.

Answer 2

I think the real question here is inheritance vs. polymorphism. In popular languages like Java the two are combined, i.e. subtype polymorphism is only achieved through implementation inheritance. Go proves that polymorphism can be achieved without inheritance, even in a statically-typed language (and this was known before Go). So the question is, if you can have polymorphism without inheritance, why would you want it with inheritance?

The modern answer seems to be... you wouldn't. Conflating inheritance with polymorphism assumes inheritance is the most common use case. Even James Gosling admits that implementation inheritance was a mistake. That isn't to say it's useless; but the use cases for inheritance could be covered by a framework or DSL rather than forced into every subtype relationship. In this regard, Go had the opportunity to learn from Java's mistake.

Answer 3

Sorry for necroposting, but it seems that the question and the answers concentrate on code reuse. We can use both inheritance and composition to reuse some code from the common "ancestor", it's true. And composition works better here.

But inheritance is primarily not for code reuse, it's for dynamic binding. The "is a" relationship can be practically formulated as follows: calling code is using interface of the object and knows nothing about particular implementation.

Pseudocode:

// Interface
class A { 
  drawMe() {} ; 
};
// Implementations
class Rect:A { 
  drawMe() {DrawRect();}; 
};
class Circle:A { 
  drawMe() {Drawcircle();}; 
};

main() {
  // We fill the array in one part of the program
  Array_of_A arr;
  arr.add(new Rect);
  arr.add(new Circle);
  // We can use the array in completely another part
  // without any idea of what the items really are,
  // only know the interface
  foreach(item from arr) {
     item->drawMe();
  }
}

In many languages (e.g. like C++) inheritance is the only practical way to say "this object implements this interface". And also it allows to do some things like code reuse, which really are better done with composition.

I know nothing of Go, but I understand your words correctly, it offers another way of defining "this object implements this interface":

every object, that has methods defined by an interface, implements this interface implicite

So if you also can call the objects by interface, it does the work of inheritance. But it additionally allows the substitution of the base class, which is why I think they call it composition. And maybe because of it being internally implemented in some way other than vtable, but I can't think of where it can make any difference.

So, inheritance can be replaced by composition if you find a way to say "this object implements this interface".

Answer 4

Nice question ...

You may want to prefer inheritance over composition when you want to distinguish semantically between "A is a B" and "A has a B". E.g. class Car may have an Engine member (composition), but may be (i.e. inherit from) a Vehicle.

I think the distinction plays out in having to maintain the number of methods shared by your two classes. When you inherit, you only need to override those (virtual) functions in the base class that you really need to; if you were to use purely composition, you'd need to re-implement every method of your member class that's public.

Ultimately, the "best" method is the one that is most suitable for your current application.

Edit:

There's a small but succinct debate about it here: http://www.sitepoint.com/forums/showthread.php?568744-When-to-use-inheritance

as well as a Wikipedia article(!) about it: http://en.wikipedia.org/wiki/Composition_over_inheritance#Drawbacks