Inheritance vs Composition?

Question

I asked similar question one month ago: Inheritance though composition?

I took the examples from this article: http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1 However, this time is a different problem. Sorry for posting a lot of codes, but it is just long, it's not difficult to read.

class Fruit {
    public int peel() {

            System.out.println("Peeling is appealing.");
            return 1;
        }
    }

class Apple extends Fruit {
}

class Example1 {

    public static void main(String[] args) {

        Apple apple = new Apple();
        int pieces = apple.peel();
    }
}

After modification, it's not longer ok:

class Peel {

    private int peelCount;   
    public Peel(int peelCount) {
        this.peelCount = peelCount;
    }    
    public int getPeelCount() {    
        return peelCount;
    }
}

Modification of class Fruit results in a compile error code.

class Peel {

    private int peelCount;

    public Peel(int peelCount) {
        this.peelCount = peelCount;
    }

    public int getPeelCount() {

        return peelCount;
    }
}

class Fruit {

// Return a Peel object that
// results from the peeling activity.
    public Peel peel() {

        System.out.println("Peeling is appealing.");
        return new Peel(1);
    }
}

The old implementation is broken. That problem can be solve by composition:

class Peel {

    private int peelCount;

    public Peel(int peelCount) {
        this.peelCount = peelCount;
    }

    public int getPeelCount() {

        return peelCount;
    }
}


class Fruit {

// Return int number of pieces of peel that
// resulted from the peeling activity.
public Peel peel() {

System.out.println("Peeling is appealing.");
        return new Peel(1);
    }
}

// Apple must be changed to accomodate
// the change to Fruit
class Apple {

    private Fruit fruit = new Fruit();

    public int peel() {

        Peel peel = fruit.peel();
        return peel.getPeelCount();
    }
}

// This old implementation of Example2
// still works fine.
class Example1 {

    public static void main(String[] args) {

        Apple apple = new Apple();
        int pieces = apple.peel();
    }
}

With the style of composition, apple is no longer is-a relationship with Fruit. It become a has-a. Methods from Fruit are delegated to Apple as inheritance. Here my questions arise:

• With wrapper methods to delegate methods from Fruit, isn't that promote copy and paste, which is a bad practice? Image if we have around 10-50 methods in Fruit. How can it is possible to inherit by composition, if there are around 50 subclasses to inherit?

• About the first example, inheritance by using extension, the author suggests that one change in the superclass will break the implementations using it. However, I wonder, why does it need to be changed? Isn't one of the OO principle "close for modification, open for extension"? In the case of author stated, I can still keep the old superclass implementation and still make it adapt to the new change. Like this:

  class Fruit {

  // Return a Peel object that
  // results from the peeling activity.
  private Peel getPeel() {
  
      System.out.println("Peeling is appealing.");
      return new Peel(1);
  }
  public int peel(){
      Peel peel = getPeel();
      return peel.getPeelCount();
  }
  

  }

Is there something wrong with adding new methods to superclass to adapt instead of changing or replacing the old methods, which will break the program structure? As far as I see, by doing this, I can still achieve the same thing as the composition example, as well as I won't have to make a lot of wrapper methods to delegate methods of superclass for each subclass.

• Because of the above reason, I conclude myself that the only time using composition is better when there are multiple inheritances, or when I need to share behaviors which vary and do not belong to one class family. For example:

interface Talkative{

 public void talk();

}

Animal class family can implement Talkative interface as well as Person class family. What do you think about my conclusion?

Answer 1

Basically, you seem to be trying to avoid changing clients that depend on an old API by creating a wrapper class.

Unfortunately, this doesn't work very well. It results in a proliferation of wrapper classes, and other cruft to create the instances of the wrapper classes. If you do to much of this, your codebase / application gets bloated, performance suffers, and your code gets increasingly hard to understand.

Better approaches are:

• Try to get the APIs right in the first place. (Duh!)
• If the API change doesn't add significant value or fix something important, put off making it.
• When you do need to make an API change, do it in a binary compatible way; e.g. add new methods rather than making binary incompatible changes to existing ones. Mark old methods as deprecated if you plan to get rid of them.
• When you have to make a binary incompatible API change, change all of the code that uses it at the same time.

The @Deprecated tag allows you to give people your APIs warning that a method should no longer be used, while giving them a window in which to fix their code to use the replacement method / alternative approach.