> > When I introduce generics to this picture I end up with more classes? We > best get specific... > - CommonSuperClassThing<X,...> > - ComplexDataStore extends CommonSuperClassThing<Feature,...> > - DataStore extends CommonSuperClassThing<SimpleFeature,...>
The real problem with that approach is there's a fundamental story we cannot tell: say in your classpath your have DataStoreA, DataStoreB and FeatureAccesA: FeatureAccessFinder.getAvaliableDataStores() should return the threee DataStoreFinder.getAvailableDatastores() should return only the first two. That is so current DataStore products can be treated as normal Features out of the box. Otherwise we need to adapt, which's what we're forced to do in the community-schema module, and we'll end up with more classes to maintain. Introducing the DataStore extends FeatureAcess hierarchy gives you the whole benefit just by using a very common refactoring (like in improving the design of existing code) method that is to pull up an interface. Gabriel ------------------------------------------------------------------------- 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
