Shown here is the application that generates CObject and CObList derived classes for Object-Oriented database management.

Some of the projects I have been working on lately have made extensive use
of CObject derived classes for encapulated data management (Object-Oriented Databases). After
creating only a few data objects, you begin to realize that the production of much of the code
could be automated. This project is a code generator to produce CObject-dervied data classes
with serialization and protected data members.

In addition to the CObject derived data classes, the application can also generate a sorted CObList
derived class to hold your data objects. For each data object you create, you can specify index
members. The list of objects is then sorted by these index members. When you add a new object to
the list, the CObList derived class ensures that it is added in the correct position in the list.

Features of this code generator:

Produces CObject derived classes, and CObList derived classes to hold the objects in a sorted list

Class name follows the selected file name

Variables are assigned data types based on Hungarian notation prefixes

Includes Serialization code

All data members are protected and accessed with Get/Set inline functions

Includes initialization code in constructor

Includes member function to duplicate the properties of an object

Includes last modified date/time

Includes Dump and AssertValid functions

Object list can be sorted on multiple fields

Limitations of the current version:

Currently, you can only create one "key" value, although with a little trickery, your could run the application multiple times to generate multiple CObList derived class and allow multiple lists.

If you change the value of one of the key fields, the list does not resort. Although it would be a simple matter to add a sort function to the CObList derived class, the difficult is that there could be multiple instances of the CObList derived class throughout your application, all containing pointers to the same objects. So if one object changed a key field, you have to resort all those lists. The question is how best to keep track of where all those lists are. I don't have an answer for that yet!

The function to add a new object to the list is not well optimized for the sorted list

There is no copy constructor

To use the code generator:

1. Select a file name for the source file output. Your header file will have the same name but with an ".h" extension. Also, the class name is derived from the file name such that Example.cpp will produce a class called "CExample", and the COblist derived class will be
CExampleList. Note that the code generator will overwrite any existing files.

2. Enter the names of the data members for the class. Data types are determined
from the Hungarian notation prefixes. The program uses the following prefixes (these are easy to change):

dt -- COleDateTime

str -- CStirng

n -- int

f -- double (not FLAG!)

b -- BOOL

rgb -- COLORREF

If you want to generate a CObList derived class to hold your objects, enter Index members for the class. These will be added to your CObject derived class. The list will be sorted by these members in the order in which they appear. The indeces will also be used for comparing objects, and will available as parameters in a constructor.

If you leave the Indeces list blank, the application will not generate a CObList derived class. Only the CObject derived class will be generated.

3. Click the "Generate" button to generate the source file and header file.

The code generator produces code using my own programming
style so you may want to adapt it to more closely follow your own style.

So that's it. I am somewhat new to OODB, so I am interested in feedback and improvements.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Share

About the Author

Bob Pittenger is founder and President of Starpoint Software Inc. He holds a B.A. degree from Miami University, M.S. and Ph.D. degrees from Purdue University, and an MBA from Xavier University. He has been programming since 1993, starting with Windows application development in C++/MFC and moving to C# and .NET around 2005 and is a .NET Microsoft Certified Professional Developer.

Bob is the author of two books:
Billionaire: How the Ultra-Rich Built Their Fortunes Through Good and Evil and What You Can Learn from Them
and
Wealthonomics: The Most Important Economic and Financial Concepts that Can Make You Rich Fast.
Visit http://www.billionairebook.net for more information.

Comments and Discussions

Seems to me that a lot of people are now starting at the database level to create objects that abstract database access. I personally love code generators because I'm a bit lazy (see sig) . The thing that I would think would make this really killer is if it were to either read a database schema or connect to a DSN and generate objects from what it finds. I've written my own code generator to do this sort of thing in the past, but it was limited because I didn't start at the database either. It just seems like the logical thing to do. I suppose it is just a larger undertaking than I am willing to take on.

Nice job even though it's been over two years.

-Matt

------------------------------------------

The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall

I (the author of the article) am currently using this technology in my fourth maor application. Here is the big problem... It takes many iterations to get the database schema the way you want it. You can spend all the time in the world planning your design, but when you see it in action, you (or the customer) gets new ideas that weren't considered before. Except now, your machine generated code has been modified, so if you regenerate it, you lose your modifications. Otherwise you have to make further modifications by hand. I have developed some work arounds from experience. All in all, it is still much better and more robust than coding everything by hand from the beginning.

IMO, there is not much point in implementing all the work to read a database scheme. Matching the DB schema to the object takes very little time at all.

I agree with you. In a perfect world we would have all of the requirements of a given project locked down from the get-go, but that's not, IMO, possible. Part of developing software is demonstrating it to your customer. This *always* introduces new ideas to them and they want it changed. I do think, however, that if you take a code generator for what it's worth, it is an extremely powerful tool that can eliminate much of the tedium.

Maybe some day AI will be good enough to figure things out, so to speak. Until then, we just rely on the computer for the parts it's good at and fill in the gaps ourselves. I have found that an iterative approach works pretty well to get you closer to the perfect code generator. For instance, if you find that you are always changing a certain part of the generated code when you first start, it is a very likely that that piece of code should be added to your code generator. I've done this many times and it really helps it to become a more and more robust application. It, obviously, doesn't remove the need for human tweakery altogether, but it sure helps to narrow the gaps.

Thanks for engaging this discussion.

Best regards.

-Matt

------------------------------------------

The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall