This may not be the answer you are looking for but ... The basic idea is you have a single frontend application that can be interfaced to any one of four, possibly more backend database platforms. So the objective is you want to make the backend database implementation transparant to the frontend application, or in oop terminology, you want to decouple the application from the database implementation. A typical way to do this would be to create an abstract definition of all the database activities you want your application to know about - this will be the "view" the application has of it's database operations which is a uniform view that is independent of the specific database implementation. Then you would write concrete classes for each database that provide the implementation details specific to each db platform. Each concrete class (family of classes) implements the common, uniform abstract database interface. So for example, a common operation the application might need would be creating parameters for a parameterized query. But SQL Server recognizes, say, an nvarchar type, while an OLEDB db platform recognizes the same parameter as a BSTR. You don't want your application to have to worry about these differences. So you would define a common abstract interface, IParameter, that describes parameter definitions in terms of a single type as far as your application was concerned, like "string", or "chararray". Then you would have separate concrete classes, like CParameterSQL and CParameterOLE that handled the details of formatting a "string" type input parameter into either an nvarchar or a BSTR, respectively. Then you would use an Abstract Factory design to instantiate the correct family of db concrete classes for the application, based on the specific DB platform. The idea is that your application only knows about IParameter and a "string" type. The CParameterSQL or CParameterOLE both implement IParameter, and hide the details of whether the "string" parameter is ultimately cast to a nvarchar or a BSTR. So that would be a typical OOP approach to this scenario. Of course, outlining the basic concept, and actually coding it are two different things. :-) C.Sylesh wrote: I can either derive the 4 data access classes from the base, or I can contain a member of the base in each one of the 4. As far as whether to inherit or instantiate common functionality in the concrete implementation classes, ask a different person, you'll get a different answer. Pe
