On Thu, 2008-06-26 at 19:45 +0200, Martin Desruisseaux wrote: > Hello Tim > > Thanks a lot for your emails, it is very welcome! > > My knowledge of Feature model is too limited for being useful, but I will > read > again your comments carefully and try to learn more. > > About factories, we are aware that they are not satisfying. An old GeoTools > version was using properties like core Java DOM. Then we switched to an other > mechanism used by Java Image I/O: factories are registered in > META-INF/services/ > directory bundled in JAR file. This mechanism has been standardized in core > Java > as of Java 6: > > http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html > > The javadoc in the above page gives an example of usage. With this mechanism, > there is no global variable that various libraries could override. However a > user wanting a factory get the set of all factory implementations available. > The > question become: which one to use. >
That's nice. If I understand it correctly the properties are localized in the JAR files, so that each implementation could theoretically work with its own set that is invisible to anybody else. That kind of scoping would solve the "global variable" problem of system properties. > > GeoTools has a mechanism for specfying the "preferred" factories using a set > of > hints. But this mechanism is complex. > > There is a demand for using an other framework like Spring. This is a > possible > approach, while it would introduce a dependency which is more of interest to > JEE > applications than JSE ones. > > Yet an other alternative is to look at what will come up from JSR-277, to be > bundled in Java 7: > > http://jcp.org/en/jsr/detail?id=277 > > So in short, the issue of factories in Geotools is not resolved. I have not > yet > a clear answer to suggest, only some possibilities open for consideration. > > Regards, > > Martin One point that I would like to make is to urge you not to lean too heavily on dynamic runtime discovery of types. Runtime discovery has the benefit that implementations can be transparently swapped out without recompiling, but that's often a "gee whiz" factor that has very little practical relevance. In exchange, it sacrifices simplicity and clarity in written code. As long as the API binding layer is small, it would be a relatively small change (though admittedly one that would require recompiling) to switch to another implementation if desired. I am imagining something like this: InterfaceObject startingPoint = StaticBindingClass.getInterfaceObject(); // everything else can now be created from startingPoint In this case, changing to a different implementation would require changing the call from StaticBindingClass.getInterfaceObject() to something else. This mechanism requires no runtime discovery of types, dynamic instantiation of objects using reflection, nor casting after getting them back. It's just plain ol' Java. The catch to this approach is that the concept of a "starting point" /must/ be part of the design of the API, not just the implementation. If the API doesn't support this design, it's almost impossible for an implementation to mimic it. One approach, obviously, is to have the starting point object be a "universal factory" that has the ability to create everything, but that's less than ideal. (If nothing else, that means that it becomes a "universal parameter" to almost every single method, both in the API and in user code. This, in turn, encourages singletons, global caches, and other things that are basically global variables all over again.) I think the best solution is to have a cascading factory pattern where data objects are also factories for the types that they encompass. For example, a FeatureDescriptor should be able to create a Feature, and an AttributeType should be able to create an AttributeDescriptor. This approach could easily be mixed with a dynamic discovery approach without diminishing either. Designing the API with such an approach in mind, though, would create a simple, easy-to-understand entry point for people who are just getting started with the framework, and it would probably be sufficiently flexible for 95% of possible applications. (I know it would be for ours.) Thanks, Tim Swanson Software Engineer Tyler Technologies, Inc. 14142 Denver West Parkway, Suite 155 Lakewood, CO 80401 Phone: Fax: 303-271-1930 E-mail: [EMAIL PROTECTED] Web: www.tylertech.com ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
