Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Designing with interfaces

One programmer's struggle to understand the interface

By Bill Venners, JavaWorld.com, 12/01/98

Page 4 of 6

interface Peelable {

    int peel();
}

class Fruit {

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

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

class Apple implements Peelable {

    private Fruit fruit = new Fruit();

    public int peel() {
        return fruit.peel();
    }
}

class FoodProcessor {

    static void peelAnItem(Peelable item) {
        item.peel();
    }
}

class Example5 {

    public static void main(String[] args) {

        Apple apple = new Apple();
        FoodProcessor.peelAnItem(apple);
    }
}

Given the above set of classes, you could later define a class Banana like this:

class Banana implements Peelable {

    private Fruit fruit = new Fruit();

    public int peel() {
        return fruit.peel();
    }
}

Like Apple, class Banana has a composition relationship with Fruit. It reuses Fruit's implementation of peel() by explicit delegation: it invokes peel() on its own Fruit object. But a Banana object can still be passed to the peelAnItem() method of class FoodProcessor, because Banana implements the Peelable interface.

As this example illustrates, interfaces allow you to get the best of both worlds. You get the flexibility of composition and the flexibility of polymorphism in one design.

Choosing between composition and inheritance

As I described in last month's article, my basic approach to choosing between inheritance and composition is that I make sure inheritance models a permanent is-a relationship. The is-a relationship means that a subclass is a more specialized form of a superclass (that the superclass is a more general form of the subclass). For example, a SavingsAccount is-an Account. I believe that modeling all (and only) permanent is-a relationships with inheritance helps maximize the code flexibility, because doing so gives inheritance a clear meaning that can help other programmers understand your code.

My main design philosophy is that its primary goal should be to maximize code flexibility, defined as the ease with which code can be understood and changed. Although I state in last month's article that composition in general yields more flexible code than inheritance, I list reasons that show composition yielding code that's easier to change, but not necessarily easier to understand. Inheritance, if you use it just for is-a relationships, gives you the flexibility advantage that your code becomes easier to understand.

My feeling, therefore, is that the way to get maximum advantage of both inheritance and composition in your designs is to ask yourself if you have a permanent is-a relationship. If so, use inheritance. If not, use composition. For more details on this design guideline, read last month's article.

Interface guidelines

Where, then, do interfaces fit into this picture? As I mention above, one major benefit of the Java interface is that they give composition a shot at polymorphism. When you use composition with interfaces, it becomes as easy to add a new front-end class (composition) as it is to add a new subclass (inheritance). But what does this tell us? Should you always use interfaces every time you use composition? Well, no. Should you avoid using interfaces in conjunction with single inheritance of class extension? Certainly not.