On 9/20/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
They can still choose to compose a SimpleFacets instance and treat it as a collection of utilities, but i'd like to make sure subclasses that only override a small piece of the functionality are easy to write.
"override a small piece" is overly generic. Base classes need to be designed carefully and *specifically* for allowing certain methods to be overridden. If you just export your current implementation and say "overidde any piece you want", you end up with a big mess in the future. Let's say someone did want to do facets slightly different, and they override getFacetTermEnumCounts. Now I come along and add a different strategy (getFieldCacheCounts) and now their class is broken because they relied on getFacetTermEnumCounts always being called. http://en.wikipedia.org/wiki/Fragile_base_class I would not expect a client to override getFieldCacheCounts or getFacetTermEnumCounts. I *could* see someone calling specific implementations though... We need use-cases to intelligently evaluate what the internal API should look like. I could see a custom query handler doing conditional faceting based on previous results: f = Faceting.getFieldCacheCounts(base_doc_set, "foo",10,false,false) if (f.getValue(0) > 100) { // OK, the first value is big... let's further split it by field "bar" DocSet newDocSet = base_doc_set.intersection(doc_set_for_top_term) f2 = Faceting.getFieldTermEnumCounts(newDocSet, "bar",10,false,false) } else { // too few values, try faceting on a different field f = Faceting.getFieldCacheCounts(base_doc_set, "baz",25,false,false) } I'll try to update my patch to pull out a getFieldFacets method that encapsulates parameter parsing and the decision of what faceting strategy to call... that way soneone could add their own method and override getFieldFacets() to call it in certain cases. I'm not sure it's really a realistic use-case though. -Yonik
