Interesting point -- worth a tangent. I also generally like the interface / abstract class pattern, where it matters, to really get the best of both worlds: clients can choose to inherit behavior or take it on themselves to provide all behavior.
This pattern only partly gets at the issue Lance mentions, which I've heard echoed from Lucene via Grant. If you add a new interface method and default implementation in the abstract class, fine -- nobody breaks. However if you add a new method for which there is no meaningful default, you have the same breakage problem. A no-op method may just hide the problem. However, the pattern does indeed do a lot to avoid this issue and I think we use it well and could do more. Stepping back -- I'm not worried about API change at version 0.x. I'll worry at 1.x, myself. Now's the time to make sure all the public APIs are there on purpose, not accidentally, because yes you can't yank them just like that later. Now is definitely the time for Big Changes as later can't be the time for it. On Sun, Apr 10, 2011 at 12:46 PM, Benson Margulies <[email protected]> wrote: > > THe eclipse pattern was to always define a pair: an interface and an > abstract class. > > On Sat, Apr 9, 2011 at 9:48 PM, Lance Norskog <[email protected]> wrote: > > Another coding pattern that causes global changes is the use of > > interfaces instead of abstract classes to define types. > > > > Open Source projects proceed by nibbling at the edges, not refactoring > > or sweeping changes. The Solr JIRA has a lot of uncommitted patches > > that people often try to use and keep up to date, even though they are > > never committed. At that point of maturity, refactoring and sweeping > > API changes are amazingly disruptive. The Solr people switched to > > abstract classes years ago for exactly this reason. > >
