[Geotools-devel] refactoring of style and filter classes

[James M. <j.m...@ge...>]

Hi all.

There is some cleaning up needed in the way that we handle Filters and 
Styles as we need to add some factory classes to cut down on dependancies.

To give an example, the filter module can parse filters encoded in XML and 
generate filters using the classes in the defaultcore module.  This makes 
it hard to switch to another implementation of the filter classes as the 
filter module is now dependent of defaultcore.

To resolve this, we need a factory interface in core and an instance in 
defaultcore such that the filter module only needs to use the factory 
interface to construct all the filters.

To do this we need to have the major filter types as interfaces in core 
with implementations in defaultcore, the trick is coming up with names for 
the interfaces and classes which are not confusing.

So far in core we have
Expression, Filter, and two exceptions.

In defaultcore we have:
ExpressionDefault
ExpressionAttribute
ExpressionLiteral
ExpressionMath
FunctionExpression
BBoxExpression
AbstractFilter
CompareFilter
BetweenFilter
FidFilter
GeometryFilter
LikeFilter
LogicFilter
NullFilter
FunctionExpression
MaxFunction
MinFunction

We need to move some/all of them up to being interfaces and leave the 
others as special cases for the defaultcore, the question is, what do we 
call them?

Option that I can think of are:
Core | Defaultcore
FidFilter, DefaultFidFilter
FidFilter, BasicFidFilter
FidFilter, SimpleFidFilter
FidFilter, ConcreteFidFitler
FidFilterInterface, FidFilter
FidFilterI, FidFilter
FidFilter, FidFilterImp

I'm not a fan of the ObjectNameInterface and ObjectNameImple style of 
naming, mostly because the idea of interfaces in Java is that you do not 
need to know when you are dealing with an interface or an object.

Basic or Simple as prefixes are probably what I would go for, though 
Concrete fits in with the GOF abstract factory pattern.

The Style classes are already defined in this way so all that is needed is 
a factory class.  That said, the use of Default as prefix in those classes 
has produced a possible line of confusion as the class DefaultStroke may 
imply a fixed standard 'default' stroke style rather than the defaltcore 
implementation of the Stroke interface.  Similarly Simple or Basic may 
imply that it is only semi functional when in fact it is complete.

This sort of naming convention is something we need to resolve so that each 
module can be consistent.

When considering this it is worth noting that it is probably better for the 
core interface to have a good name rather than the defaultcore 
implementation as the Factory methods will return instances of the 
Interface name rather than the implementor.

e.g.
public FidFilter makeFidFilter(String[] fids);

The factory in defaultcore will construct a DefaultFidFilter but the 'user' 
will see only a FidFilter unless they cast it.

Incidentally, it is possible, at least for the filters, to avoid putting 
the interfaces into core at all by using generic methods in the factory, so 
that the make methods look something like:
public Filter make Filter(int type, Object arg1, Object arg2, Object arg3);

Though, personally I think this is messy though we could use it to enable 
the introduction of extra expressions or filters in specific implementaions.

I'd welcome any thoughts or comments on the above ramble :)

James



-- 
James Macgill
Center for Computational Geography http://www.ccg.leeds.ac.uk
Spell Checker (c) Creative Spelling inc (aka my dyslexic brain)
http://www.geotools.org a client side java mapping toolkit.