Payroll example shoot-out between Top Mind and Robert Cecil Martin's OOP example:
Related links:
www.codeproject.com 
(GUI code based on the book, but only a subset of features are shown)
The Table Oriented Programming (TOP) version can almost be characterized as a "domain-specific sphreadsheet with joins" because the calculation sequences and formulas are stored in tables (although a non-tabled formula version is also shown). The key to the process are two tables that interact with each other. There is a "line-item master" table of all potential line-items and related (optional) formula, and another table that has employee-specific "feature selectors", along with an optional value parameter that can represent employee-specific amounts such as hours or sales quantities (formula may or may not use this value). These two tables are joined to bring it all together.
(If one needs more than one parameter, then one can use "hidden" or visible line-items. I debated dispensing with the dedicated parameter value and just using line-item references, but found the dedicated parameter just simplified lots of formula specifications that a power-user would be "coding". Technically there are two parameters because there is also a description addendum to provide optional specifics to the line description.)
Unlike a spreadsheet, however, the app uses line-item "category" names instead of explicit "cell" addresses. A running total of each line-item category is kept via an associative array.
Summary of alleged advantages of TOP version as claimed in link:
Flexibility - Many concepts such as taxes, union dues, etc. are table driven instead of hard-wired into app code. Such can be added or changed with little or no app code change. (An Sap Corporation-like model of "configuration experts" is assumed. These configuration experts do not need to be programmers, but only need basic knowledge of accounting and spreadsheet-like formulas.)
Simplicity - Less code per features than Martin example. (I suppose one could argue that "coding" is still needed to set up formulas and categories. But, at least administrators, AKA "power users", can learn to make necessary changes without knowing the programming language behind it. It becomes mid-level changes instead of tech-level.)
Integration-Friendly - By using tables, user/customer sites can interface with the system easier without having to use language-specific interfaces. For example, a sales tracking system can transfer info into the payroll system via RDBMS to distribute commisions. Location-specific calculations could also be performed as a separate sub-system based on attributes in the tables and then integrated back in via the table-oriented interface.
Discussion moved from Shifting The Burden Of Proof:
Furthermore, the Payroll Example is highly questionable as an illustration of anything. I developed real payroll systems for years, and consider both samples laughably trivial; in particular the OO code is not reflective of a growing trend in modern real-world OO programming, which is to focus far more on computational abstractions and much less on "domain modelling". -- DV
I actually tend to agree with that to a large extent. But that is not what is being peddled just yet. Many influential OO proponents don't want to concede domain modelling just yet. (If my slicing your text bothers you, just let me know and I'll rework it differently.)
You are welcome to introduce real-world situations that would test [OO vs Table Oriented Programming] harder.
That's a good idea. As time permits, I shall present an OO implementation of the payroll calculations at www.cra-arc.gc.ca
If you notice, Payroll Example does not actually implement org-specific formulas and conditionals. Thus, a PDF with hundred pages of formulas tells us very little. It instead provides a vessel to place such formulas; a domain-specific "spreadsheet" almost. Further, if its formula system is not sufficient enough for some computations, such as involved Turing Complete calculations, it is designed such that an organization-specific "calculation engine" could obtain the raw values from the primary payroll system (such as hours worked and rate classifications), do calculations, and then "dump" them back into the payroll system using plain-jane ODBC with SQL. As long as the org-specific engine sticks with the conventions, it will all fit. In other-words integratability and extendibility. You guys tend to focus on magic of specific languages with internal data, but rarely address interoperability. Academics tend to do this in general: focusing more on how to invert a matrix rather than on how to obtain and prepare the data for the inversion. It reminds me of Page Anchor "can-opener" at Practitioners Reject Formal Methods Discussion. -top
Sorry, the above I don't follow. I've simply proposed to implement the Canadian tax deduction calculations using OO techniques as a realistic business-oriented scenario. My implementation (written in Java) is inspired by actual production code (also written by me, in C++) that implements the same specification, but which I'm unfortunately not at liberty to distribute. When it's done (I've finished about 50% of Option1, as of this writing), I'll post it. I'd like to challenge you to implement the same using Table Oriented Programming so that we can compare the two approaches. You may use my code as the specification for your implementation, if you'd rather not plow through the rather tedious documentation or have to learn the intricacies of Canadian payroll.
I'm curious, by what factor/metric(s) do you think the OOP version will by better on? Further, my design does not preclude a large part of the calculations being done in an OOP language. It's designed to act as a "glue tool" of sorts if need be. It's kind of like report-writers in Desktop Databases: they all provide a generic one, but one would use a dedicated one, like Crystal Reports if they need something heavy-duty. Similarly, my tool has a built-in "formula processor", but allows easy interfacing with external formula processors. I don't even dispute that some algorithms may be easier to represent in OOP (although I've seen very few actual specimens). My point here is that its not an either/or choice, unless you perhaps present an OO version of a payroll glue-tool. -t
No, I was merely intending to provide a straightforward, simple, but usable implementation of a realistic, real-world business scenario -- the Canada payroll tax calculations. It's a Payroll Example, but is by no means the same, or even similar to, the Payroll Example already presented here.
I am not entering into this with any preconceived notions of which approach will be better on any particular factors or metrics. Rather, I intend it to be -- initially at least -- a source of interesting observations and a basis for rational comparisons. Observation, after all, is the starting point of all science. Also, I'm genuinely interested in comparing the two approaches. I have an open mind about pure procedural programming and Table Oriented Programming, and would like to compare and contrast it with conventional OO programming.
Fair enough. Let the code times roll...
'Tis done. See Payroll Example Two
And comments about that code can be found in Payroll Example Two Discussion.
See also: Employee Types, Why Is Payroll Hard, Business Rules Metabase
See original on c2.com