There have been many major successful libraries where the interfaces
change from one (major) version to the next.
Programmers are used to it, and quite apt at dealing with it.
But, in the cited case, it is a perfect example where Field being an
interface and DefaultField being a default implementation would have
been a good solution.
This allows backwards compatibility for most applications, but more
advanced implementations are not hindered by being tied to idea of
what a field should be.
Some would argue that all that Field needs is
FieldData getField(String name); and void setField(String
name,FieldData data);
and FieldData has
toBytes(); fromBytes()
with various implementations and decorators that easily allows String
to be used as a FieldData. Since String is final this is a bit more
difficult since you could not do
class MyString extends String implements FieldData
which is why for common known JDK classes you would have in DefaultField
setString() and getString() and others...
Writing custom versions of IndexReader and IndexWriter was very
difficult because them being tied to a directory (a set of files). If
you have an implementation that doesn't need this, you end up with a
very bad OO hierarchy. We had an implementation that had no concept
of files, yet you would never have realized that by looking at the
hierarchy.
On Mar 24, 2008, at 6: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]
