Running a business is complicated. A construction business is more complicated than most, with plenty of quirks. Because of that, writing construction accounting and estimating software is a challenge. There’s always one more weird thing that needs to be handled.
To help keep the programmers sane amidst all that complexity, Goldenseal uses OOP: object-oriented programming. It uses code that looks more or less like the real world. With luck, OOP makes everything a bit more logical and easier to understand.
For example, to handle change orders, there’s a CChangeOrder class. It stores data for change orders, and does math and other tricks for them.
Object classes can have parents and siblings. The parent of a CChangeOrder is a CBreakdownTransaction (also the parent for all other transactions that have a breakdown table). Allowances have change orders as their parent. They inherit most of the same behavior as change orders, but tweak a few things that are different.
Our staff spends plenty of time designing objects and their contents. If it’s done well, coming back years later isn’t be too painful. Stuff still makes sense. If OOP is done poorly, then it turns out to be a confusing mess.
As we hook up Qt with our existing code, we find some of each.
All the data classes like CChangeOrder are great. No need to touch them at all. So far the database code is also working well.
Breakdown tables are more challenging. We had to write them from scratch in the original Goldenseal, so they have thousands of code lines for screen drawing, mouse clicks, and other interface details. Most of that is handled automatically by Qt table classes. Our staff is still figuring out what can be deleted from our old code, and what has to stay. Fortunately, we don’t need to clear out all the clutter right now. Sometimes it’s better to wait and be sure it really can be tossed. Sorta like cleaning the garage.
The hardest kind of OOP in Goldenseal is the link between what you see on the screen, and what’s stored on disk. We have a DB_RecordViewer class that handles that: record loading, saving, and everything in between. Its children are specialized to manage specific types of records: for example, CChangeOrderViewer for change orders.
As with tables, there is plenty of excess code in there. Newer frameworks already handle much of the nitty-gritty of screen display. We still need record viewers to handle the quirks, but they talk with a Qt object for most things.
Last winter we got records loading from disk onto the screen, and last week we got data saving from the screen back to disk. It’s coming along.