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?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
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.,
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.
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 ]