Bad idea for you Gabriel.... just remove the word Complex
- FeatureReader extends Reader
- DataStore extends Data
- FeatureSource extends Source
- FeatureStore extends Store
- FeatureLocking extends Locking
You are correct that naming is the hardest part.
> Indeed that was my first intention but got strong advice about avoiding
> generics in our API. Also an approach introducing generics will throw a lot
> of warnings in client code I guess.
>
There may be away; I agree that generics are required if you are
narrowing parameters. Initially only return values
were being narrowed.
Three alternatives
- covers parameter narrowing using FeatureQuery and Query as the example
- covers data access type narrowing using FeatureType /
SimpleFeatureType as the example of a result made more specifc
- covers data api type narrowing using Reader / FeatureReader as the
example of an api made more specific
GENERICS (super class is a parent of both general Feature access and
specific SimpleFeature access )
interface Store<F,S,Q> {
S getSchema();
FeatureReader<F,S> getReader(Q query, Transaction );
...
}
interface DataStore extends
SuperStore<SimpleFeature,SimpleFeatureType,Query>{
}
interface FeatureAccess extends
SuperStore<Feature,FeatureType,FeatureQuery>{
}
EXPLICIT (subclass/superclass relationship exists; datastore would have
a few new general methods available from its parent)
interface FeatureAccess {
FeatureType getSchema();
Reader getReader( FeatureQuery, Transaction );
...
}
interface DataStore extends FeatureAccess {
SimpleFeatureType getSchema();
FeatureReader getReader( Query, Transaction );
...
}
(note the method: Reader getReader( FeatureQuery, Transaction ); can
still be called on DataStore).
SEPERATE (ie methods are named similar by convention only)
interface FeatureAccess {
FeatureType getSchema();
Reader getReader( FeatureQuery, Transaction );
...
}
interface DataStore {
SimpleFeatureType getSchema();
FeatureReader getReader( Query, Transaction );
...
}
Jody
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
