C++ Class Data

[cryptic_blade]

I am working on the design for a new application and want to make the
program fully object oriented. I have built and used C++ classes
before, but never with a database driven application. Should classes
handle reading and writing their property data to the database table
themselves, or should they rely on an outside "DataHandler" custom
class or function specific to the application.

If I hard code specific database/table/query information into a
class's structure, it no longer become portable because it is
"bound" to database. I want to be able to reuse my classes and I
fear that writing storage routines "inside" the class definition
will render my classes less portable. How do most of you implement
class usage when class data need to be stored in databases and later
re-populated into a new instance of the class?

Example:

I want to build a ficticious object oriented program that allows the
user to enter in the year, make, and model of their favorite sports
car. Then that data is saved to a database table. The user also has the
ability to search the "cars" database table and display a list of
all previously saved cars. I also need to be able to reuse the classes
in other programs without needed to reconstruct the database and tables
used in the first program. It is possible that I may need to build
another program that deals with cars, but doesn't store the car
information in a database.

I already know I need a "Car" class, but should the Car class take
care of reading and writing to the database directly through methods I
expose? If I build-in database storage into the class I can't reuse
the class in another application without creating a database with a
"car" table. What to do???

Class: Car
Property1: Year
Property2: Make
Property3: Model
Method1: getCar(carID) <- populate object with database record data?
Method2: setCar(Year, Make, Model) <- update database record with
object data?

Hope I made my question clear enough.

Thanks in advance

 

[Victor Bazarov]

I am working on the design for a new application and want to make the
program fully object oriented. I have built and used C++ classes
before, but never with a database driven application. Should classes
handle reading and writing their property data to the database table
themselves, or should they rely on an outside "DataHandler" custom
class or function specific to the application.

[..]

This is not a language question, unfortunately. What you're trying
to do is to come up with a decent OO design of your model. "Class"
and "object" and "database" are language-neutral concepts. Try
posting to comp.object or to a database newsgroup. You need help
defining parts of your system and laying out relationships between
them, and C++ has really nothing to do with it. Once you figure out
all those language-neutral details, we can help you put it into C++
terms.

V

 

[cryptic_blade]

I posted this question here since I specifically want the perspective
of C/C++ programmers. Those terms may be "language-nuetral", but
unfortunately implementation DOES vary across programming platforms.
It's the sad truth that OO methodology differs depending on the
language. So I ask once again, can I get this question answered here or
not?

Regards

 

[David Hilsee]

I am working on the design for a new application and want to make the
program fully object oriented. I have built and used C++ classes
before, but never with a database driven application. Should classes
handle reading and writing their property data to the database table
themselves, or should they rely on an outside "DataHandler" custom
class or function specific to the application.

If I hard code specific database/table/query information into a
class's structure, it no longer become portable because it is
"bound" to database. I want to be able to reuse my classes and I
fear that writing storage routines "inside" the class definition
will render my classes less portable. How do most of you implement
class usage when class data need to be stored in databases and later
re-populated into a new instance of the class?

[snip]

At the very least, people tend to prefer to have their classes remain
independent of the particular database product so that they could easily use
another some time in the future. It is usually considered bad practice for
your "domain" objects to depend on a particular storage mechanism. There
are a few patterns that are design to avoid that sort of problem (e.g.
"Serializer"
http://www.ubilab.org/publications/print_versions/pdf/plop-96-serializer.pdf).
Of course, if your storage mechanism is highly unlikely to change, then
there's less of a reason to avoid that coupling. The comp.object newsgroup
would probably offer better suggestions.

 

[Dan Cernat]

[snip]

It's the sad truth that OO methodology differs depending on the
language. [snip]
Regards

yeah, right.

 

[cryptic_blade]

Don't beleive me? I'll give you an example. Coldfusion, which I realize
isn't a "formal OO language", yet is a language, boasts CFCs
(coldfusion components), which for all intents and purposes act as
objects once they are instantiated on the coldfusion server. CFCs treat
all code not contained within CFCs function bodies as contructor code.
Access to the This and Super scope are also provided in a limited
fashion. However, the biggest short coming perhaps, is that fact the
these so-called objects have no destructor!!! Let me say that again,
THERE IS NOT A DESTRUCTOR! Let's see you try to implement that as a
standard OO class model!

So, as I was saying. The OO methodology depends entirely on the on the
language and its complience with OO standards.

Cheers

 

[David White]

Don't beleive me? I'll give you an example. Coldfusion, which I
realize isn't a "formal OO language", yet is a language, boasts CFCs
(coldfusion components), which for all intents and purposes act as
objects once they are instantiated on the coldfusion server. CFCs
treat all code not contained within CFCs function bodies as
contructor code. Access to the This and Super scope are also provided
in a limited fashion. However, the biggest short coming perhaps, is
that fact the these so-called objects have no destructor!!! Let me
say that again, THERE IS NOT A DESTRUCTOR! Let's see you try to
implement that as a standard OO class model!

So, as I was saying. The OO methodology depends entirely on the on the
language and its complience with OO standards.

To some extent, but it's hard to see how a C++ answer to the question you've
asked would differ in any significant way from the language-neutral answer
you'd get in an OO design course. If what you say is true then general OO
design books and courses that include example designs wouldn't even be
possible without specifying the language they are designed for.

DW

 

[upashu2]

Should classes

handle reading and writing their property data to the database >table
themselves, or should they rely on an outside "DataHandler" >custom
class or function specific to the application.

If I hard code specific database/table/query information into a
class's structure, it no longer become portable because it is
"bound" to database. I want to be able to reuse my classes and I
what about my idea?

Your class (car etc,) will have a function Serialize(CStream *), where
CStream class will be used as stream class to read / write data.
make a stream base Class CStream, and its derived class for file
operation, CFileStream, for database operation CDatabaseStream etc.
These stream classes should support >>,<< so that Serialize() function
can read/write data through just >>, << operators.

 

[David White]

If I hard code specific database/table/query information into a
class's structure, it no longer become portable because it is
"bound" to database. I want to be able to reuse my classes and I
what about my idea?

Your class (car etc,) will have a function Serialize(CStream *), where
CStream class will be used as stream class to read / write data.
make a stream base Class CStream, and its derived class for file
operation, CFileStream, for database operation CDatabaseStream etc.
These stream classes should support >>,<< so that Serialize()
function can read/write data through just >>, << operators.

Good idea, but I would ditch the 'C' on all the class names.
http://www.jelovic.com/articles/stupid_naming.htm

DW

 

[cryptic_blade]

I understand what you are saying about OO being taught as
language-nuetral and shouldn't be tied to a specific language. I feel
the theories taught in OO design are "mostly" practical, but many of
them are unfortunately tied to the environemnt you are designing in.
For example, in relational database thoery, there is a concept of 5th
normal form, maybe even higher. Can you image how inefficient designing
an actual database that conforms to 5th normal form would be? Even the
most seasoned DBAs typically only built relationships in databases to
conform up to 3rd normal form only. My point is merely that OO design,
like relational database theory, work flawlessly in a language-nuetral
way in textbooks, but real life experience in multiple languages has
taught me otherwise.

Cheers