lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Engels" <>
Subject incorrect OO in lucene source?
Date Tue, 20 Apr 2004 00:12:34 GMT
Lucene is often cited as an excellent example of OO design.

I see several areas where this does not seem to be the case, mainly because
of the Lucene code uses abstract base classes where it should be using
interfaces, and other cases, where an interface makes reference to an
abstract base class as a method/return parameter.

It seems the abstract base classes were created so there was a place to put
the static 'helper' methods. Would it not be better to have separate
interfaces and abstract base classes that the implementations could extend
if necessary?

Some examples are listed below. Am I missing something, or is the code
structured this way for a reason?


The main problem seems to be the use of IndexReader in many interfaces, when
it should be using a Searchable. Otherwise, what is the point of Searchable.

The following object use chain shows the 'pointlessness' of Searchable:



The Query object has the method:

public Query rewrite(IndexReader reader) throws IOException...

but the entire search package is based on 'Searchable's, should it not be

public Query rewrite(Searchable searchable) throws IOException...

If not, the entire idea of 'external' searchable implementations break,
because the end up having to 'know' an IndexReader, and IndexReader is a
baseclass, etc.

The same goes for

public Weight weight(Searcher searcher);

should this not be a 'Searchable'?


The Weight interface has the following:

Scorer scorer(IndexReader reader) throws IOException;

Should it not be

Scorer scorer(Searchable searchable) throws IOException;

The same goes for explain().


It seems that Searchable was created because IndexReader was not an
interface, but the methods have not been changed to use a Searchable instead
of IndexReader.


It seems many of the 'search' package classes use a 'Searcher', when they
should be using a 'Searchable'. If these core classes really need the
methods defined in 'Searcher', then these methods should be moved to


Shouldn't 'Filter' just be an interface, with the method

boolean filter(int docnum);

as to whether or not the document should be filtered?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message