Hello Tim Tim Swanson a écrit : >> (..snip... following on): >> >> http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html >> > > 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.
There is no properties in the sense of the ones managed by java.lang.System. This is a runtime discover mechanism. If a JAR contains an implementation of some factory, just putting this JAR in the classpath makes the implementation visible to the whole library or clients of that library. However the above just lists the factory implementations discovered on the classpath; it doesn't said which one to choose among the choices. Making a choice is left to user's reponsability, but it is done on a case-by-case basis (every time a ServiceLoader is instantiated - there is no global variable). > 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. Yes... I also tend to believe that our current factory mechanism is too complex (thats why I said that it would be the very first thing to put on the table for GeoTools 3). I have not yet a clear picture of what should be done however. > 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. I'm limited again by my lack of knowledge of Feature in GeoAPI and GeoTools, so I don't know how their factory system work. In the case of the factory systems I know about (mostly referencing), I don't think that a pattern where data objects (CoordinateReferenceSystem) are also factories for the types they encompass (Datum, CoordinateSystem) are applicable: * CoordinateReferenceSystem encompass CoordinateSystem, which encompass CoordinateSystemAxis. Because all those objects are immutable by design, how a CoordinateReferenceSystem could create a CoordinateSystem before the later created its CoordinateSystemAxis? * It would introduce some duplication (e.g. GeodeticDatum are used by both GeocentricCRS and GeographicCRS - do we need a createGeodeticDatum(...) method in both CRS?) * It would increate the API size, mixing data object accessors with factory methods. However maybe it is applicable to features, I don't know. Some cascading pattern could be applied to factories, but deconnected from the data objects. The "starting point" mentioned at the begining of the quoted text was actually proposed in GeoAPI in the form of "CommonFactory", which was intented to be the starting point for fetching other factories: http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/go/CommonFactory.html However this CommonFactory is part of the GO module - it would probably needs to be put in some more central place and generalized (it currently returns only a subset of all possible factories). GeoTools has something similar to the above CommonFactory, but scattered on a module-by-module basis rather than in some central place. An other difference which is specific to GeoTools is that we expects an optional Hints argument, which may be null. If non-null, this Hints allows the user to said some preferences like "I want whatever factory which build CRS object with longitude before latitude". http://javadoc.geotools.fr/snapshot/org/geotools/referencing/ReferencingFactoryFinder.html I think that the Factory pattern can be preserved, but the FactoryFinder pattern needs to be simplified and/or centralized. I'm thinking to something along the line of: public interface FactoryFinder { <T extends Factory> T getFactory(Class<T> type); <T extends AuthorityFactory> T getAuthorityFactory(Class<T> type, String authority); } Those two single methods would be suffisient for fetching every kind of GeoAPI factories, including Geometry, Referencing, Feature, etc. There is cast, but they are applied automatically by Java 5. Martin ------------------------------------------------------------------------- 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
