Payroll Example with Source Code (OO vs P/R)
in [OOP]
|
Prev: Using static factories to create two objects with bidirectionallinking
Next: 2nd RFD: remove comp.object.moderated moderated (LAST CALL FOR COMMENTS)
From: topmind on 30 Apr 2007 02:16 I've finally posted my coded version of Robert Martin's payroll example: http://www.geocities.com/tablizer/payroll2.htm Now, show me exactly how Martin's code (or any OO version of it) is clearly better. Here's your chance to put your money where your mouth is and show OO kicking P/R's bumbum with actual code. -T-
From: coeval on 30 Apr 2007 07:13 On 30 Apr, 07:16, topmind <topm...(a)technologist.com> wrote: > I've finally posted my coded version of Robert Martin's payroll > example: > > http://www.geocities.com/tablizer/payroll2.htm > > Now, show me exactly how Martin's code (or any OO version of it) is > clearly better. Here's your chance to put your money where your mouth > is and show OO kicking P/R's bumbum with actual code. > > -T- Find Robert Martin's Initial example at http://www.codeproject.com/books/PatternsPractices.asp
From: topmind on 30 Apr 2007 11:39 On Apr 30, 4:13 am, coeval <hvfre...(a)gmail.com> wrote: > On 30 Apr, 07:16, topmind <topm...(a)technologist.com> wrote: > > > I've finally posted my coded version of Robert Martin's payroll > > example: > > >http://www.geocities.com/tablizer/payroll2.htm > > > Now, show me exactly how Martin's code (or any OO version of it) is > > clearly better. Here's your chance to put your money where your mouth > > is and show OO kicking P/R's bumbum with actual code. > > > -T- > > Find Robert Martin's Initial example athttp://www.codeproject.com/books/PatternsPractices.asp Thanks for the link. Note that this looks a bit different than what I remember from the book. I mainly based mine on the requirements listed, which did not dictate any particular user interface that I remember. I can get you the page number on a later date if you wish. But so far that is not a major issue. It is the philosophical design and code org differences that are the big issue. -T-
From: AndyW on 30 Apr 2007 19:38 On 29 Apr 2007 23:16:43 -0700, topmind <topmind(a)technologist.com> wrote: >I've finally posted my coded version of Robert Martin's payroll >example: > >http://www.geocities.com/tablizer/payroll2.htm > >Now, show me exactly how Martin's code (or any OO version of it) is >clearly better. Here's your chance to put your money where your mouth >is and show OO kicking P/R's bumbum with actual code. > >-T- I found it an interesting read. However, I have always considered payroll to be a procedural application rather than an OO one - mainly because it is in its raw form primarily lists and calculations. I would like to see both candidates implement an automative parts catalog complete with diagrams. It would handle nested assemblies where an assembly is a collection of related parts and each part in an assembly can itself be an assembly and cross referencing (many assemblies are used on multiple vehicles or multiple unrelated assemblies). ---------------- AndyW, Mercenary Software Developer
From: topmind on 1 May 2007 11:38
AndyW wrote: > On 29 Apr 2007 23:16:43 -0700, topmind <topmind(a)technologist.com> > wrote: > > >I've finally posted my coded version of Robert Martin's payroll > >example: > > > >http://www.geocities.com/tablizer/payroll2.htm > > > >Now, show me exactly how Martin's code (or any OO version of it) is > >clearly better. Here's your chance to put your money where your mouth > >is and show OO kicking P/R's bumbum with actual code. > > > >-T- > > I found it an interesting read. > > However, I have always considered payroll to be a procedural > application rather than an OO one - mainly because it is in its raw > form primarily lists and calculations. > > I would like to see both candidates implement an automative parts > catalog complete with diagrams. It would handle nested assemblies > where an assembly is a collection of related parts and each part in an > assembly can itself be an assembly and cross referencing (many > assemblies are used on multiple vehicles or multiple unrelated > assemblies). This sounds like a CAD-like application. CAD is allegedly a better fit to navigational structures because of the nested nature of parts (although it is not necessarily a "pure" tree). However, this nested nature tends to be somewhat relative in practice. The accounting, procurement, and materials department may not care much about the nested nature of physical construction. I won't make any claim about what tools/paradigms are best for CAD because that is outside of my hands-on experience. But with business and management apps, there are not too many "true trees" such that a user's perspective tends to depend upon their work function or specific concern at the moment. OO often talks about "modeling the real world". However, modeling a given user's perspective is a more useful goal in my observation. Relational so far is the best "relativity engine". Locational breakdowns (country, state, city, etc.) are probably the closest pure tree I encounter, but even those have non-tree viewpoints or exceptions. For example, somebody doing demographic studies may divide areas into demographic categories (rural, urban, liberal, conservative, etc.) to do marketing studies by those categories. There are even companies who will sell demographic info by zipcode. I remember this distinctly because because the software vendor wouldn't let us modify the base tables nor put tables in the same DB, so the only way to associate such info with specific customers was to create a parallel table in another DB. (IIRC, the granularity was finer than zipcode such that a simple lookup wouldn't do.) Further, internal slice-ups of regions, divisions, etc. may not match up to other division viewpoints. I've encountered a situation where there were boundary slices created for different reasons than the common ones we used at first. Thus, it was a different independent "map". The nesting of one was not the same as another. For example, political voting boundaries sometimes don't match postal boundaries due to squabbling over gerrymandering. Thus, simple containment hierarchies are often not sufficient. But still that brings up the question of where such classifications/ taxomies should be. A CAD system is a kind of database, or at least database-like. I don't think it is wise to hard-wire source-code to match domain classifications/taxonomies *regardless* of whether the structure is navigational or relational. Thus, polymorphism and sub- typing seems against that goal either way. I find it best to decouple them, at least for larger-scale stuff. Maybe in CAD there is a reason to couple them, but again, that is outside of my domain. Thanks for your feedback > > > ---------------- > AndyW, > Mercenary Software Developer -T- |