Object oriented design
-
I was designing the database part of a module to be developed in C++. Let me explain the scenario. I have to access 4 different databases which are not related in any way. So I created 4 classes that holds the business logic to manipulte each of the databases. Then I thought of creating a database access class for each of the dbs to implement the data access code using ADO, so that the business logic class can call the public functions of these classes to get things done. Then I found that the Connection object is common for all the 4 classes, also there are a few methods that are common, like the OpenDatabase, CloseDatabase, IsOpen, GetProviderError etc etc. So I created a base class for that. Now I have two options, 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. Remember, I need all the functionalities implemented in the base class as such in all the 4 classes that implement the business logic. It was found that most people say that we must try to go for weaker coupling if possible, that way I must go for containment. But then I will have to write stub functions to call the base object's function, which is an overhead. I would appreciate it if somebody can give me an advice in this regard. Thanks in advance, Sylesh.
-
I was designing the database part of a module to be developed in C++. Let me explain the scenario. I have to access 4 different databases which are not related in any way. So I created 4 classes that holds the business logic to manipulte each of the databases. Then I thought of creating a database access class for each of the dbs to implement the data access code using ADO, so that the business logic class can call the public functions of these classes to get things done. Then I found that the Connection object is common for all the 4 classes, also there are a few methods that are common, like the OpenDatabase, CloseDatabase, IsOpen, GetProviderError etc etc. So I created a base class for that. Now I have two options, 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. Remember, I need all the functionalities implemented in the base class as such in all the 4 classes that implement the business logic. It was found that most people say that we must try to go for weaker coupling if possible, that way I must go for containment. But then I will have to write stub functions to call the base object's function, which is an overhead. I would appreciate it if somebody can give me an advice in this regard. Thanks in advance, Sylesh.
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