Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• 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

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

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 2 of 6

This Jurassic Park scenario potentially could be represented by the following inheritance hierarchy:

The diamond problem can arise in inheritance hierarchies like the one shown in Figure 1. In fact, the diamond problem gets its name from the diamond shape of such an inheritance hierarchy. One way the diamond problem can arise in the Jurassic Park hierarchy is if both Dinosaur and Frog, but not Frogosaur, override a method declared in Animal. Here's what the code might look like if Java supported traditional multiple inheritance:

abstract class Animal {

    abstract void talk();
}

class Frog extends Animal {

    void talk() {

        System.out.println("Ribit, ribit.");
}

class Dinosaur extends Animal {

    void talk() {
        System.out.println("Oh I'm a dinosaur and I'm OK...");
    }
}

// (This won't compile, of course, because Java
// only supports single inheritance.)
class Frogosaur extends Frog, Dinosaur {
}

The diamond problem rears its ugly head when someone tries to invoke talk() on a Frogosaur object from an Animal reference, as in:

Animal animal = new Frogosaur();
animal.talk();

Because of the ambiguity caused by the diamond problem, it isn't clear whether the runtime system should invoke Frog's or Dinosaur's implementation of talk(). Will a Frogosaur croak "Ribbit, Ribbit." or sing "Oh, I'm a dinosaur and I'm okay..."?

The diamond problem would also arise if Animal had declared a public instance variable, which Frogosaur would then have inherited from both Dinosaur and Frog. When referring to this variable in a Frogosaur object, which copy of the variable -- Frog's or Dinosaur's -- would be selected? Or, perhaps, would there be only one copy of the variable in a Frogosaur object?

In Java, interfaces solve all these ambiguities caused by the diamond problem. Through interfaces, Java allows multiple inheritance of interface but not of implementation. Implementation, which includes instance variables and method implementations, is always singly inherited. As a result, confusion will never arise in Java over which inherited instance variable or method implementation to use.

Interfaces and polymorphism

In my quest to understand the interface, the diamond problem explanation made some sense to me, but it didn't really satisfy me. Sure, the interface represented Java's way of dealing with the diamond problem, but was that the key insight into the interface? And how did this explanation help me understand how to use interfaces in my programs and designs?

As time went by I began to believe that the key insight into the interface was not so much about multiple inheritance as it was about polymorphism (see the explanation of this term below). The interface lets you take greater advantage of polymorphism in your designs, which in turn helps you make your software more flexible.

Ultimately, I decided that the "point" of the interface was:

Java's interface gives you more polymorphism than you can get with singly inherited families of classes, without the "burden" of multiple inheritance of implementation.

A refresher on polymorphism
This section will present a quick refresher on the meaning of polymorphism. If you are already comfortable with this fancy word, feel free to skip to the next section, "Getting more polymorphism."