Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. C++ Design

C++ Design

Scheduled Pinned Locked Moved C / C++ / MFC
c++databasedesignbusiness
2 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    csylesh
    wrote on last edited by
    #1

    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.

    B 1 Reply Last reply
    0
    • C csylesh

      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.

      B Offline
      B Offline
      Bob Stanneveld
      wrote on last edited by
      #2

      Hello, You can do different things depending on your needs. If your base class is likely too change a lot and your system is very large (it takes a lot of time to compile and link), I definitly would go for the private data member. From a logical design point of view, the most obvious thing to do is to derive your specialized classes from the base class. This way, your small accessor functions can be inlined better and you don't have to do much additional allocations, since that adds a lot of overhead. Remember this: containment comes at a price. Overhead is the price to pay. How much you contain depends on each scenario... for example, a widely used class should contain all the implementation details at the cost of more runtime overhead. A not so widely used class doesn't need to contain all the details.. etc.. Hope this helps :-D Behind every great black man...             ... is the police. - Conspiracy brother Blog[^]

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups