Payroll Example with Source Code (OO vs P/R)
topmind
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-
coeval
Find Robert Martin's Initial example at
http://www.codeproject.com/books/PatternsPractices.asp
topmind
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-
AndyW
wrote:
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
topmind
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-
AndyW
wrote:
I was actually thinking more along the lines of the factory parts
manuals that someone like Honda produce. About a thousand pages full
of parts diagrams and all of the relationships.
Since these are now part of their ordering system, it is very much a
common type of application to develop (I suspect most automative
vendors would use a similar system).
I would agree with you in your premise that if the application is just
pushing lists and numbers as many business applications pretty much
do, then relational/procedural can be just fine. However, there are
many enterprise applications that dont do this (and many of them
probably dont even have a UI for users to interact with).
I consider this is an OO forum and I would expect the debate to be
about OO programs solving OO solutions as well as
relational/procedural. I couldnt quite see the point behind posting
up a relational/procedural solution to a relational/procedural problem
in an OO forum without at least also comparing it to an OO solution to
an OO problem :)
topmind
Again, there would be more classifications to such parts than just
their physical location after assembly. I think relational does a
better job than navigational when things participate in multiple
viewpoints/classifications (examples already given). Navigational
arrangements seem to focus on one primary classification/taxonomy at
the expense of others.
>
> I would agree with you in your premise that if the application is just
> pushing lists and numbers as many business applications pretty much
> do, then relational/procedural can be just fine. However, there are
> many enterprise applications that dont do this (and many of them
> probably dont even have a UI for users to interact with).
>
> I consider this is an OO forum and I would expect the debate to be
> about OO programs solving OO solutions as well as
> relational/procedural.
If you are saying that there are kinds of problems that fit OOP better
and some that fit P/R better, I won't necessarily disagree. However,
this viewpoint is not widespread. Those who like OO seem to think that
just about everything should be OO.
> I couldnt quite see the point behind posting
> up a relational/procedural solution to a relational/procedural problem
> in an OO forum without at least also comparing it to an OO solution to
> an OO problem :)
>
If we could come to an industry consensus about what works well with
OO and what doesn't, that would be very helpful. Sticking OO where it
may not belong can be frustrating. I've seen some good table-oriented
tools go to waste when OO hype hurt their sales and mucked them up
with paradigm identity crisis when trying to OO them up like putting a
truck driver in a wedding dress.
Gabriel Claramunt
Gabriel
http://gabrielsw.blogspot.com/
"topmind" <top...@technologist.com> wrote in message
news:1177913803.0...@c35g2000hsg.googlegroups.com...
topmind
Gabriel Claramunt wrote:
> What would be the criteria for the comparation?
That has always been a sticky issue when comparing paradigms or
techniques. It is even tough to find objective metrics to say why code
blocks are better than GoTo's. A lot of it is psychological in nature,
and everybody's psychology is different. I gave descriptions as best I
could of why I feel my version is superior, or at least "not worse":
Recap:
1. Flexibility - R. Martin hard-wired concepts into his design that
are table-configurable in this one. Such concepts include employee pay
"types" (hourly, commission, exempt, etc.), union dues, sales
commissions, etc.
(It is often claimed that OOP results in less app code that has to be
changed per change request. By making those concepts be table-driven,
my version can result in zero app lines having to be changed. At least
in this case, I proved that claim wrong.)
2. Simplicity - The approach shown here is less code even though it
does more than Martin's, such as displaying actual stubs and allowing
user-configurable line-items.
3. Integration-Friendly - By using tables, user/customer sites can
interface with the system easier. For example, sales-commission-
related information can be populated into the EmpCharges table without
having to know anything about the application programming language:
they "talk to" tables, not OOP classes. Such systems or utilities are
sometimes referred to as "feeder systems"; and are a common need in
real-world business apps.
Gabriel Claramunt
laguages should have a similar SLOC per Function Point rate.
Then you can measure 2) with total FP and total SLOC for each solution. For
1) a set of different unnanticipated change requests should be established
(proably by a third party, trying not to favor any paradigm), the average
SLOC (discarded + added) will give you a rough measure of flexibility. For
3) maybe creating multiple different scenarios with different technolgies
(databses, flat files, XML, and direct conections to mainframes,
webservices, etc.) and measure the change like 1).
Anyway, my guess is that roughly you'll get similar results, but at least
you can put numbers on it.
Gabriel
http://gabrielsw.blogspot.com/
"topmind" <top...@technologist.com> wrote in message
news:1178124433.7...@e65g2000hsc.googlegroups.com...
topmind
Gabriel Claramunt wrote:
> It would be better if you can measure those attributes. To be fair both
> laguages should have a similar SLOC per Function Point rate.
> Then you can measure 2) with total FP and total SLOC for each solution. For
> 1) a set of different unnanticipated change requests should be established
> (proably by a third party, trying not to favor any paradigm), the average
> SLOC (discarded + added) will give you a rough measure of flexibility. For
> 3) maybe creating multiple different scenarios with different technolgies
> (databses, flat files, XML, and direct conections to mainframes,
> webservices, etc.) and measure the change like 1).
> Anyway, my guess is that roughly you'll get similar results, but at least
> you can put numbers on it.
Past attempts at similar scenario analysis had at least two problems:
1. Each party disagreed about the frequency/likelyhood of the various
scenarios. OO proponents fealt that OO-favoring changes were more
common than my experience dictates. For example, I observe the
"divorce" of apparently mutual-exclusive concepts more frequently than
they do. OO authors will often subclass employees (or "pay types")
into commission-based and salary-based. But I've seen companies give
sales commissions to salaried employees. Thus, I see hard-wiring of
mutual exclusiveness as a risky code choice, prone to more code
changes down the road. This is why I treat such as independent
features with any enforcement of current/initial mutual-ex. as being a
validation issue: if they later separate, then one only has to remove
or disable the validation rule. OO'ers, on the other hand claim that
such is not common enough to justify giving up subtyping.
2. There were differing opinions about what kind of code changes were
harder or riskier to undertake. For example, should having to modify 8
lines of code in a single named unit (function/method) count as much
as having to modify a total of 2 lines of code, but in different named
units?
What I have come to conclude is that people optimize their coding
preference for how they *perceive* the world, change frequencies, and
coding risk. Nobody purposely makes life hard for themselves, we just
have different ways of perceiving what is "messy" or risky code. We
prevent "accidents" as we see them. We simplify what bothers us based
on experience and personal preference. Some have fast eyes and slow
fingers and visa versa. We optimize our virtual mental desk
differently to fit our brains. Thus, "paradigms are subjective" is
still my standing tentative conclusion. It's all about psychology in
the end, not math nor science.
And, this is why software engineering is stuck in the dark ages as far
as objective labor productivity metrics. In the old days they would
optimize factories by watching how people's arms, fingers, eyes, legs,
etc. moved to perform tasks. One could measure angles, repeat
movements, distances traveled by limbs or legs, etc. We cannot do the
same with software development until we can Xray neurons in actions
and know what is happening. However, if we knew how the brain worked,
we would build them and do away with human workers.
I am just trying to demonstrate that P/R is not objectively worse and
to describe using inspectable code why I prefer it.