Actually, the Lucene philosophy is more aggressive. The general perception is that interfaces should be avoided entirely.
The problem is that you cannot know how many people are implementing the raw interface itself. Better to have the abstract class serve in the place of the interface so that you know that you aren't messing people up. Even if there is no default behavior for a method, you can at least throw an UnsupportedOperationException. If you add a method to the interface, however, your users can't use the new jar at all without recompiling. The need for stability then pushes all such changes to major version boundaries which is massively painful for innovators and can totally stifle new development. We aren't to the point where we face those problems, but I would rather avoid interfaces where plausible because of that experience. On Sun, Apr 10, 2011 at 12:09 PM, Sean Owen <[email protected]> wrote: > 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. >
