Andrea wrote: > >> Since I already have classes in my own code base that account for > >> SQL dialects I can only say that - as time goes by - I find more > >> and more differences that must be accounted for. I haven't > >> encapsulated these vendor-specific helper functions as an > >> interface, rather I use a set of static singleton classes which I > >> can extend at any time if I find another case where vendor specific > >> code must be hidden from the rest of the application. (They are > >> part of a small library I can use in different projects.) > > I've lost you here. With the abstract class approach we can give > the datastore a subclass of SQLDialect that deals with the Oracle > details (for example) and the datastore can call it without knowing > about Oracle at all. How do you do the same (or something similar) > with a set of static singletons?
If SQLDialect is indeed an abstract class then we DO have the same approach. With "set" I just meant that I had split different tasks/concerns into several abstract classes, e.g. database login, simple queries, spatial ops. My worries were about an *interface* being too unflexible for future requirements. But by using an abstract class it is indeed no problem to add a method. BTW. The concept of concealing database vendor specific code from the rest of the application is obviously a common task. I have already heard similar needs from different developers now and I wonder if there is a library (or a de facto standard implementation) for this already available. If not, maybe this would be a good time for creating one? -- Matthias Basler [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
