Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"

Robert Martin wrote:
On 2007-01-21 13:59:25 -0600, "topmind" <topmind@xxxxxxxxxxxxxxxx> said:

Isolation creates duplication of concepts and can make it more
difficult to use the existing power and abilities of RDBMS. Most of the
code in your book is WASTED on translating back and forth between two
medium-to-high-level concepts: OO and relational. It is like spending
effort translating between Japanese and Spanish and back rather than
get anything real done.

The payroll system in the book is partitioned into code that knows
about the DB schema, and code that does not. The dividing line is a
set of interfaces that translate high level concepts like "GetEmployee"
into appropriate SQL. To the left of the interfaces the code deals
with Employees. To the right the code deals with SQL, tables, rows,
and columns.

In any application, OO or not, this translation must take place. All
we have done with the code in the book is to assign a place for that
translation.

First off, this could be done without OOP. We could have functions that
wrap the SQL. Thus, it is not really an OO-specific thing.


There is no duplication. There is no waste. There is simply a
separation of concerns. Those concerns would exist regardless of
whether they were separated or not.

It is additional code and likely additional work. The more beurocracy
you put between the RDBMS and the app code, the more places you will
often have to change. For example, if a new attribute or table is
needed for a given calculation, then likely there will be two 2 units
that need changing: the SQL along with the SQL wrapper's interface, and
the app code that uses it. However, if the SQL was together, then only
one unit needs changing. Thus, wrapping is more effort: one has to make
2 hops instead of one. These kinds of changes can and do happen quite
often. Swapping DB vendors is fairly rare. Thus, you are paying a
nearly GUARENTEED indirection tax of about 25% on on-going code
maintanence in order to prevent a roughly once-per-10-year event, and
such effort is only about a 10-day effort on medium projects (if you
combine the testing with general new-version testing). Thus, over a
10-year period, the heavy wrapping may cost at least 3 hours a week,
adding up to more than 1,000 hours in 10 years. This to prevent an
80-hour DB swap effort?[1] One would have to swap vendors roughly every
18 months to break even!

The economic calculatioins are just plain against this in most custom
application shops. It just does not add up. My version of your app
would be roughly 1/2 to 1/4 the same amount of code. Shorter code in
general is usually easier to learn, modify, test, understand, read, and
debug. Your code is full of "red tape". It is mostly martialing stuff
back and forth between instantiations and interfaces istead of doing
domain-related calculations. It smells of a programmer jobs program
better than any spend-happy liberal could ever pull off. (I shouldn't
mind from my perspective, but one does get bored dealing with bloated
red-tape code. I like to spend my time on real work, not red tape.)

I also would like to see your comments on taxonomy issues. (The
SQL-wrapping issue has been beaten to death on comp.object anyhow.)
Excerpt from my critique:

(begin quote)

Page 352 and 353: Figure 26-1 and Figure 26-2

Martin commits a common OO mistake of making a hierarchy of "employee
types", or at least "payment types" (hourly, commissioned, and
salaried). "Types" are often a poor modeling decision in business
applications because they cannot handle orthogonal traits very well.
Martin gives tons of lip service about making applications easier to
change without lots of code overhaul. However, hierarchical OO classes
are expensive to de-hierarchy.

In fact, I've witnessed first-hand an actual scenario that busts
Martin's hierarchy. I've worked at a place where it was decided that
any employee can receive sales bonus. If they sold the company's
products to their neighbors or friends, they qualified for commissions.
We live in a heavily sells-oriented capitalist society, so preparing
for such a situation should be a no-brainer.

If you look at my schema below, you will notice that there is nothing
that forces a mutually-exclusive choice of "payment types". The
equivalent of Martin's 3 classes is driven mostly by the "empRates"
table. If they are an hourly employee, then they have a corresponding
hourly rate row in the table. If they are salaried, then they have a
monthly rate (per specifications on page 350). If they get a sales
commission(s), then the commission rate(s) are also there. We are
making the design assumption that they are not necessarily mutually
exclusive.

You may ask what keeps somebody from being both an hourly and a
salaried (monthly) employee. If such combinations are not allowed, then
it can be prevented via data entry validation and/or database triggers.
The point is that we are not hard-wiring the allowed or disallowed
combinations into our basic design to give us feature flexibility.
Validating such combinations is treated also as mere data configuration
issue, and not a large-scale code feature.

(End Quote -- yuk, I need to rework some of my writing on that
website.)

[1] If one uses features that are very vendor-specifc, then DB vendor
swapping can take much longer. However, finding new-vendor ways to do
things the prior way is still going to be needed regardless of wether
you wrap or not. It is not effort wrappers save. Swapping in general
won't be free even under wrapping, so I may have understated my point
by not "charging" the wrapped version for swap hours.


--
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx

-t-

.

Relevant Pages

  • Re: Prolog to SQL ..??
    ... >> There are lots of nice tricks, but translating Prolog to SQL is not ... >> There are obviously times when a Prolog clause or 2 can be translated ... >> If you want something REALLY tedious, try Prolog to Yacc. ...
    (comp.lang.prolog)
  • Re: Prolog to SQL ..??
    ... > There are lots of nice tricks, but translating Prolog to SQL is not ... > so strange if you just treat SQL like an assembly language;-) and use ... > There are obviously times when a Prolog clause or 2 can be translated ... The problem with Yacc is that he make only finite state automata, ...
    (comp.lang.prolog)
  • Re: Critique of Robert C. Martins "Agile Principles, Patterns, and Practices"
    ... code in your book is WASTED on translating back and forth between two ... To the left of the interfaces the code deals ... How many getEmployeeBySomeCriteria methods do you think you will end up ... If you have a table employee and a class employee, ...
    (comp.object)
  • Re: Prolog to SQL ..??
    ... There are lots of nice tricks, but translating Prolog to SQL is not ... so strange if you just treat SQL like an assembly language;-) and use ... There are obviously times when a Prolog clause or 2 can be translated ...
    (comp.lang.prolog)
  • Crystal 8.5 - SQL generated by Select Expert loses logical meaning
    ... This is translating to the following ODBC SQL: ... The correct SQL should be: ... Crystal is evaluating this as: ...
    (microsoft.public.vb.crystal)