RowFilter again: tension between minimal api and ease-of-use?
same question posted over at OTN
for your convenience, copied here:
(yeah, I'm still struggling with RowFilters ;-)
The minimal api I'm referring to is ComparisonType: it has values before, after, equal, not-equal. This is complete in that comparisons like before-and-equal can be expressed by a logic not-after.
An important aspect of ease-of-use (as I see it :) is consistency: learn one pattern, way-of-life, dialect .. and re-use incomparable contexts. Now the pattern to use a RowFilter on comparables is
<br /> RowFilters.compareFilter(Before, comparisonValue, index);<br />
Obviously, that pattern can't be used for comparisons like "compound" comparsions:
<br /> // ease-of-use-version, can't be done<br /> RowFilters.compareFilter(Before-And-Equal, cv, i);</p> <p>// instead have to break the habit<br /> RowFilter after = RowFilters.someFilter(After, cv, i);<br /> RowFilters.notFilter(after);<br />
hmm ... now in a framework I could hide the two-line effort behind a factory method
<br /> RowFilters.beforeAndEqualFilter(cv, i);<br />
here the type of comparison is drawn out of the parameterlist into the method name. For a consistent api, that factory would have to have cover methods beforeFilter, afterFilter ... etc.
An alternativ approach would be to have a new ComparisonType (unfortunately, it's an enum - not extendable) with all combinations and re-implement the comparing filters. BTW, the latter is necessary anyway, as it should be applicable to all Comparable.
Hmm ... (incoherent?) mumblings, mainly because I can't really make up my mind ;-) Opinions, please?