Artima just published an excellent interview with Erich Gamma which I strongly recommend to anyone interested in writing software for the long run.  Erich makes a great job at explaining the power of interfaces while reminding that abstract classes can sometimes be useful as well.

There are a few points I’d like to emphasize in this interview:

Since changing interfaces breaks clients you should consider them as immutable once you’ve published them. As a consequence when adding a new method to an interface you have to do so in a separate interface. In Eclipse we take API stability seriously and for this reason you will find so called I*2 interfaces like IMarkerResolution2 or IWorkbenchPart2 in our APIs.

First of all, notice that they are prefixing interfaces with "I" which, if you are a regular reader of this blog, is a convention that I like a lot and use everywhere.  Once you start realizing the importance of interfaces, you want to find a way to read a piece of code and immediately spot whenever a concrete class is being used instead of an interface.  This convention goes a long way toward this goal and in my eyes, a piece of code is completely "pure" if all the type names it uses start with I.

More generally, this technique is a lesson that Java programmers have been very reluctant to learn.  I am not sure where this resistance comes from but it might have something to do with the fact that this conventionn was popularized by Microsoft in the Component Object Model way back in 1995.

With the incredible success of .dll and reusable VB and OCX components, Microsoft quickly learned the importance of making published interfaces immutable, so they enforced this by providing tools to generate unique ID’s (across the planet) for every new COM interface that you define.  Interestingly, Sun started introducing this convention recently, albeit sparingly:  org.xml.sax.ext.EntityResolver and EntityResolver2, java.awt.LayoutManager and LayoutManager2, etc…

What the article doesn’t say is how exactly you can leverage this pattern to actually write reusable code.

It’s actually pretty easy.

Imagine that you wrote a program to make coffee:

public void dispense(ICoffeeMaker coffeeMaker) {

  coffeeMaker.pourBeans();

  coffeeMaker.makeCoffee();

}

At some point, your coffee maker starts supporting pouring milk and since ICoffeeMaker is now immutable, you need to create another immutable interface.  We could call it ICoffeeMaker2 if there was no other suitable name, but IMilkCoffeeMaker is probably better in this case:

public interface IMilkCoffeeMaker extends ICoffeeMaker {

  public void pourMilk();

}

Note:  I initially used the example of decaf coffee for this but it occurred to me that this would be an implementation change, and not an interface modification.  Milk makes more sense because we are adding a functionality that hadn’t been anticipated by the first version of this interface.

Your code now becomes:

public void makeCoffee(ICoffeeMaker coffeeMaker) {

  if (coffeeMaker instanceof IMilkCoffeeMaker) {

    ((IMilkCoffeeMaker) coffeeMaker).pourMilk();

  }

  coffeeMaker.pourBeans();

  coffeeMaker.makeCoffee();

}

As you can see, this is quite straightforward.  And it probably makes you cringe a little…  After all, weren’t you warned over and over again to avoid instanceof as much as possible, and more generally, that your code should not rely on the existence or implementation of subclasses?

This advice still stands, but like all advice, it has exceptions.  And future evolution as illustrated in the snippet above is a high enough reward that you should consider this approach when writing Truly Reusable Code.

This technique is being used in many places in Eclipse, and it’s actually so common that the Eclipse team generalized this principle by creating the IAdaptable class.  It is extremely simple:

public interface IAdaptable {

  /**

  * Returns an object which is an instance of the given class

  * associated with this object. Returns <code>null</code> if

  * no such object can be found.

  *

  * @param adapter the adapter class to look up

  * @return a object castable to the given class, 

  * or <code>null</code> if this object does not

  * have an adapter for the given class

  */

  public Object getAdapter(Class adapter);

}

There is a lot more to say about this interview and I don’t want this post to become too lengthy, so I’ll just wrap up for now by observing that this philosophy is quite at odds with what XP is trying to achieve, which is a nutshell is "Do the simplest thing that can possibly work". 

The XP philosophy is way too extreme for me (hence its name, I suppose) and I have always stayed clear of it as an absolute rule.  The approach explained above gives you a good counterpoint to this philosophy, and armed with these two tools, you will be able to make the right decision on how extensible you want your code to be.