Thanks for the meeting Justin (and IanT and Polio) was great to see enough people turn out. I will be around at 5UTC for the other timeslot if there are people interested who could not attend the first one.

As for the naming question, we have utility classes:
- JTS, SLD that work with existing data structure using static final helper methods - Styles, FeatureTypes, Schemas, Features, Filters that also work with existing data structures using static final helper methods

And we also have special utility classes called "Builders" that take a Factory and make creation easier to use:
- StyleBuilder, ExpressionBuilder and so on

This is all pretty clear and consistent, however we do have an annoying borderline case - transformation (code that manipulates a data structure, and as such needs to do some creation using a factory).

So basically utility methods that cannot be done as static final!

I have been doing is this:
1. Taking any "transform methods" copying their implementation to an Object method 2. Asking them to use a factory field, rather then direct use of a default Factory 3. Setting them up with a no argument Constructor() using the default Factory
4. Allowing for a Constructor( Factory ) and setFactory( Factory )
5. Creating a single static field holding a default implementation
6. Making the origional static methods call this default implementation
7. Providing a setter method so the default can be replaced
8. Deprecating the effected static final methods with instructions to use the replacements

All of this makes sense, and will allow for factory use, wont break existing code and offers a quick hack for code that *needs* to change how geotools works today ...

Q: Do I need a name for this kind of use? These are not pure utility classes, they change functionality depending on how they
are configured.

It should be noted that some code escapes this treatment, FeatureType.duplicate( Feature ), AttributeType.duplicate( Object ) allow for transformation methods to be written referring back to the original code that created them, at the expense of a backpointer in all data objects...




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to