On Apr 10, 2011, at 3:28 PM, Ted Dunning wrote: > Actually, the Lucene philosophy is more aggressive. The general perception > is that interfaces should be avoided entirely.
I'd mod that a little bit, in that we generally avoid interfaces, but if they are small and very well defined it's OK. Often times, it only makes sense them if they have one or two methods (one might even say just one method). If you need more methods, then it likely makes sense to have multiple interfaces. Moreover, params should be future proof when possible (i.e. you pass in a config object instead of enumerating all the different parameters, that way you can add new parameters w/o defining a new method). Thus, for things like Comparable they make sense since there is only one method, for bigger things, Abstract classes are just easier to deal with most of the time. > > 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. +1. It's just too hard to predict the future and it's really painful to break interfaces for most people. > > 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. >>
