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