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 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."