I have to agree with the blog (it terms of interfaces/classes and
'why Lucene isn't all that). Of course, it seems like we have faced
almost the exact same problems.
If you read farther down in the comments there is a very specific
example that explains the problem quite well.
There is also a reference to why "an interface should define at most
one member" is a poor decision, and prohibits some fairly standard OO
designs
abstract classes are a huge pain and end-up exposing much of the
implementation.
anyone that has done complex swing work knows the problems of
Component and Container being classes and not interfaces
still, Lucene is still the best...
On Mar 24, 2008, at 4:32 PM, Doug Cutting wrote:
Chris Hostetter wrote:
in my opinion other blog he links to hits the nail on the head a
little better (i remember reading this last year) ...
http://kirillosenkov.blogspot.com/2007/08/choosing-interface-vs-
abstract-class.html
The rule of thumb there is good too:
"An interface should define at most one member."
Interesting related note: there's another recent blog where the
lack of interfaces in Lucene (specificly for the Query hierarchy)
is listed as one of the main reasons "Why Lucene isn't that good" ...
http://www.jroller.com/melix/entry/why_lucene_isn_t_that
Perhaps Lucene should have an FAQ about interfaces versus classes?
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]
