Interface vs Abstract

[Stan James]

I just added a couple bullets and a note to the FAQ on Interface vs Abstract Class.

I don't think I'd ever seen it mentioned in our many discussions on the topic that you can add a public method to an Abstract Class without breaking all the classes that extend it, but if you add a method to an interface, you have to fix all the implementers. Puts a different spin on the "flexibility" issue.

Comments, suggestions, improvements?

[Ernest Friedman-Hill]

I don't know how much you want to write about this issue, but there's actually quite a bit more that could be said.

First, note that adding a method to an interface breaks compilation of an implementing class, but not binary compatibility. If class A implements I, then it will still work against a later version of I.class that adds new methods. Only when you try to recompile will there be a problem -- or if somebody tries to call the missing methods, of course. This is subtle, but sometimes important, as it helps ensure the binary forward compatibility that lets old Java programs continue to work on new JVMs.

Second, there is a widely used (if ugly) hack-around for the issue you describe, which is to use a subinterface; i.e.,

interface I {}
interface I2 extends I { /* more */ }
 
void doSomething(I ii) {
    if (ii instanceof I2)
        doSomething((I2) ii);
    else
        // whatever   
}
 
private void doSomething(I2 ii) { ...

The Eclipse APIs use this extensively; instead of adding to "I", they'll create an "I2" and tell people to switch to using it; but code that just implements "I" will still compile, and still work.

[Raghavan Muthu]

The idea of using a Sub-interface looks cool EFH .

But is that the ONLY possible and non-breaking alternative? Otherwise they will have to pay for the modification overhead in all other other implementors. Is that right?
[ December 03, 2007: Message edited by: Raghavan Muthu ]