public interface Factory
This interfaces forms the core of the Geotools plug-in system, by which capabilities can be added to the library at runtime. Each sub-interface defines a service. Most services are set up with concrete implementation being registered for use in a service registry, which acts as a container for service implementations.
Service registries don't need to be a Geotools implementation. They can be (but are not
limited to) any ServiceRegistry subclass. If the standard ServiceRegistry (or its Geotools extension FactoryRegistry) is selected as a container
for services, then factory implementations should be declared as below (select only one way):
META-INF/services/classname file where classname is the fully
qualified name of the service interface.
FactoryRegistry.scanForPlugins() will be invoked.
ServiceRegistry#registerServiceProvider in application code.
In addition, it is recommended that implementations provide a constructor expecting a single
Hints argument. This optional argument gives to the user some control of the factory's
low-level details. The amount of control is factory specific. The geotools library defines a
global class called Hints that is ment as API (i.e. you can assume these hints are
supported). Factories may also provide information on their own custom hints as part of their
javadoc class description. Examples:
An application supplied a datum factory hint, being passed to a datum authority factory so that all datum created from an authority code will come from the supplied datum factory.
An application supplied a FeatureFactory (ensuring all
constructed features support the Eclipse's IAdaptable interface), being passed to a
org.geotools.feature.FeatureTypeFactory so that all FeatureTypes
constructed will produce features supporting the indicated interface.
As seen in those examples this concept of a hint becomes more interesting when the operation being controlled is discovery of other services used by the Factory. By supplying appropriate hints one can chain together several factories and retarget them to an application specific task.
Hints,
FactoryRegistry| Modifier and Type | Method and Description |
|---|---|
Map<RenderingHints.Key,?> |
getImplementationHints()
Map of hints (maybe unmodifiable) used by
this factory to customize its use.
|
Map<RenderingHints.Key,?> getImplementationHints()
FactoryUsingVolatileDependencies).
The primary purpose of this method is to determine if an existing factory
instance can be reused for a set of user-supplied hints. This method is invoked by FactoryRegistry in order to compare this factory's hints against user's hints. This is
dependency introspection only; FactoryRegistry never invokes this
method for creating new factories.
Keys are usually static constants from the Hints class, while values are instances
of some key-dependent class. The key set must contains at least all
hints impacting functionality. While the key set may contains all hints supplied by the user,
it is recommended to limit the set to only the hints used by this particular factory
instance. A minimal set will helps FactoryRegistry to compare only hints that matter
and avoid the creation of unnecessary instances of this factory.
The hint values may be different than the one supplied by the user. If a user supplied a
hint as a Class object, this method shall replace it by the actual instance used, if
possible.
Implementations of this method are usually quite simple. For example if a datum authority factory uses an ordinary datum factory, its method could be implemented as below (note that we should not check if the datum factory is null, since key with null value is the expected behaviour in this case). Example:
Map hints = new HashMap();
hints.put(Hints.DATUM_FACTORY, datumFactory);
return hints;
Copyright © 1996–2019 Geotools. All rights reserved.