Our staff is still working on the 70+ lists in the new accounting software. Most behave properly now, but the ones with tables are a struggle. They have extra quirks.
For example, Delivery Methods use a “step table” to calculate charges for shipping or deliveries. If you change a row, the next row down also changes. The table makes sure the amounts are sequential, and it fills special text into the last row. Change the calculation method, and the steps can be money or numbers. The charges can be money or percents. The table has a lot of interface for just a couple square inches of screen area.
We want to write general code that works for all the tables. The way source code is organized inside Goldenseal and TurtleSoft Pro makes that harder. Both projects use object-oriented programming (OOP). It was a new concept when we started using C++ in the early 90s. Now it is mainstream.
OOP helps with a big problem: modern apps are complicated. Adding a GUI can easily double or triple the amount of source code for an app. It’s not just the 2x or 3x as much text to write. The code also needs to coordinate with 2 or 3 times as much other stuff. Those numbers multiply, so the net result is 4x to 9x the effort and complexity.
When done well, OOP source code is almost like sentences that explain exactly what they are doing. We never could have finished Goldenseal without tools to navigate the massive volume of stuff inside. OOP made it possible.
Writing our new accounting software means lots of time spent inside that 30 year old code. With hindsight, OOP does have its flaws. The problems are especially apparent for list tables.
In Goldenseal, every list needs several classes to make it work. For example, delivery methods have CDeliveryMethod (data), CDeliveryMethodViewer (interface) and CDeliveryMethodTable (table).
The plus side is that anything related to deliveries is easy to find. It works great if that is what you’re working on.
The minus happens when you try to add a whole new interface. The quirks in list tables are spread out in 60+ different classes. It’s too scattered.
There is an opposite way to program, called a finite state machine (FSM). Most games use one. It puts every possible situation into one huge switch statement, often with 1000s of branches. That can be overwhelming in its own way, but at least everything is in one place. No need to traipse through many files.
It’s not an either-or choice: a code base can use both. We tried writing a mini-state machine for the Qt list table, with branches for each type of list. The verdict? It probably is better, if we had designed it that way from the beginning. But, a major rewrite is too much effort. There are other ways that will take less time.
Still, it was a good experiment. Future iOS and Android apps that talk to TurtleSoft Pro probably will use a blend of state machine and OOP.
Dennis Kolva
Programming Director
TurtleSoft.com
