Re: Inheritance versus Composition

printdude1968@gmail.com wrote:


Use inheritance to model "is-a": Derived is-a Base.

In other words, when the derived object /is/ a base object, like a Circle is-a
Shape.

Use composition to model "has-a": Thing has-a Property.

It turns out that most of the time a flexible, extensible model will have a
lot more "has-a" than it will "is-a". The number of times you can truly model
something "is-a" something else is smaller than many think.

For example, a typical way to model UnmodifiableList, like in the Collections
class method, is to create a wrapper List around the modifiable List. Have all
setX() methods or add() methods throw an UnsupportedOperationException and
delegate the get methods to the modifiable List, held as a member.

public class UnmodifiableList<T> implements List<T>
{
   private List<T> list;
   public UnmodifiableList( List<T> list )
   {
     this.list = list;
   }

   public void add( T t )
   {
    throw new UnsupportedOperationException( "unmodifiable" );
   }

   public T get( int index )
   {
     return list.get( index );
   }

   // ...
}

It might be tempting to implement UnmodifiableList as inheriting some
modifiable type, but that turns out to be really limiting compared to having
it "have-a" list of the appropriate base type.

The rule, also in Joshua Bloch's excellent /Effective Java/, is "favor
composition over inheritance". That means think of the model first in terms of
"has-a". Then if you have a compelling argument that something "is-a"
something else, meaning generally that you explicitly designed the base class
for inheritance (/ibid./), and only after you overcome your prejudice in favor
of composition, you will create an inheritance hierarchy.

Read Josh Bloch's book and it will help you triangulate on the principles.

-- Lew