Jody Garnett wrote:
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.
Not sure you can come up with a good name. "transformation" is a pretty
broad description and entails alot of things. I dont think we need to
come up with a name so much as agree that this is an issue that cross
cuts builders and utility classes alike. Both should be good citizens,
allowing clients to override dependencies when need be.
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
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------
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
