Interface vs. abstract class

[Sean Owen <sr...@gmail.com>]

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
<bi...@gmail.com> 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 <go...@gmail.com> 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.
> >

Re: Interface vs. abstract class

[Grant Ingersoll <gs...@apache.org>]

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 <sr...@gmail.com> 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.
>> 

Re: Interface vs. abstract class

[Benson Margulies <bi...@gmail.com>]

I have this idea that this can't possibly be a good universal
restriction, but I'm not sure how to phrase the objection except to
raise the idea of, say, Comparable<T> and related interfaces. These
have the flavor of 'aside from its day job, a class can participate in
one or more some other protocols.'

Re: Interface vs. abstract class

[Ted Dunning <te...@gmail.com>]

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 <sr...@gmail.com> 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.
>