Yeah, I tend to think Open Source development should favor abstract
classes, since there is no way of knowing all the different things so
many varied users will come up with over time. I suppose one could
argue for more "major" upgrades to offset that, or more relaxed rules
about interfaces changing (which I have argued for.) I still think,
given the significant amount of time between our releases, the
supposed "hurt" of adding to an interface would not be as great as
people think. Still, I don't know that I want to find out,
either :-) I also think there are means available of communicating
the changes significantly in advance as to minimize the alleged pain
that is coming. Do people really do 1 year plus designs of search
engines, where they don't expect to upgrade at all? I would guess
most of our releases have new functionality that people end up
changing their code to take advantage of, so, again, an interface
change may not be as painful as it once was, especially since the code
is pretty darn mature.
In the end, I don't know what the right answer is. I remember early
in my career I didn't see much point in interfaces and favored
abstract classes, then someone made me "see the light" and then coming
into Lucene land, I went back to favoring abstract classes. Now, I
think I tend to use each one where it makes sense, but that is at the
application level, and I control the touch points, so, it doesn't
really apply at the Lucene level.
-Grant
On Mar 24, 2008, at 7:20 PM, Doug Cutting wrote:
Steven A Rowe wrote:
In the comments on the blog post, the author (Kirill Osenkov)
agrees with a dissenter (Alexander Jung, a.k.a. "AJ.NET"), who re-
states the rule of thumb as:
"An interface should define at most one contract."
But what if you want to expand the contract? For example, Field was
initially just <String,String>, a fine contract. Field has been
generalized to be <String,String|Bytes|Reader|TokenStream>, all
without breaking applications. While in hindsight this evolution
may seem obvious, no one forsaw it. APIs that are too general are
confusing. It's best to be clear about what's supported and what's
not. Over time, one may add more features, generalize, introduce
new levels of indirection, etc., as demand warrants. It is
impossible to know which APIs will grow in advance, and wrong make
them overly general from the start. So they must evolve. But if
you break applications in the process you waste too much of your
time responding to confused users instead of making progress. Also,
happy users lead to more contributors and a stronger project.
Interfaces do little to help this process and much to hinder it.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
