lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd VanderVeen <...@part.net>
Subject Re: incorrect OO in lucene source?
Date Tue, 20 Apr 2004 14:14:40 GMT
Erik Hatcher wrote:

> Robert,
>
> I agree with your sentiment about interfaces.  I haven't looked into 
> the specifics of what you mention about IndexReader though.
>
> Out of curiosity - is there something about Lucene's design that is 
> preventing you from extending Lucene?  Pragmatically speaking, we 
> shouldn't change anything unless there is a compelling reason to do 
> so, and while a clean architecture is a nice ideal, if it ain't broke 
> don't fix it :)
>
>     Erik
>
>
> On Apr 19, 2004, at 8:12 PM, Robert Engels wrote:
>
>> 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:
>>
>> Searchable->Query->Weight->IndexReader
>>
>> -----
>>
>> 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
>> 'Searchable'.
>>
>> -----
>>
>> 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: lucene-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
I have had similar wishes recently for interfaces for TokenStream and 
Analyzer.

---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message