Payroll Example
Payroll ExamplePayroll example shoot-out between TopMind and RobertCecilMartin's OOP example:
Related links:
(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:
Discussion moved from ShiftingTheBurdenOfProof:
Furthermore, the PayrollExample 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 TableOrientedProgramming] harder.
That's a good idea. As time permits, I shall present an OO implementation of the payroll calculations at http://www.cra-arc.gc.ca/E/pub/tg/t4127-jan/
If you notice, PayrollExample 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 TuringComplete 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 PageAnchor "can-opener" at PractitionersRejectFormalMethodsDiscussion. -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 TableOrientedProgramming 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 DesktopDatabases: they all provide a generic one, but one would use a dedicated one, like CrystalReports 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 PayrollExample, but is by no means the same, or even similar to, the PayrollExample 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 TableOrientedProgramming, and would like to compare and contrast it with conventional OO programming.
Fair enough. Let the code times roll...
'Tis done. See PayrollExampleTwo
And comments about that code can be found in PayrollExampleTwoDiscussion.
See also: EmployeeTypes, WhyIsPayrollHard, BusinessRulesMetabase
CategoryExample, CategoryBusinessDomain, CategoryObjectOrientation
EditText of this page
(last edited June 16, 2013)
or FindPage with title or text search