Practically speaking, the huge advantage of the abstract class is that you have lower update requirements and less duplicated code when augmenting the interface. Yes, you can do the dual thing, but the practical experience with Hadoop and Lucene has been that using just the abstract class which is named as if it were an interface works about better in the long run. The update requirements become very onerous when you are dealing with more than one package that have to be updated (and which can't for some reason be updated simultaneously).
When adding methods, the standard practice is to add an implementation that throws UnsupportedOperationException or something similar. Yes, you can do this with interace+abstract if *everybody* codes just the right way, but with the abstract only approach, there is one less thing for people to do wrong. I took a long time to come around to this pattern of coding, but I finally agree that publishing abstract classes really is better except where you have to have an interface (for RPC or multiple inheritance). It only takes a little bit of outside coding to run into the problem and the social cost can be enormous. On Tue, Nov 24, 2009 at 1:09 PM, Sean Owen <sro...@gmail.com> wrote: > ... > Abstract classes afford the possibility of adding methods plus > implementation, without breaking anybody, so yeah I'm into abstract > classes. But then that's no argument against an abstract class + > interface, which would add a small bit of flexibility too. >
