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

How many getEmployeeBySomeCriteria methods do you think you will end up
with in a normal payroll application?

I imagine it will be quite a few,

Only a few ways of fetching employees? By name, by employment no, by
SSN, by department, by city.... But I guess that you will do it the OO
way, fetching all employees and select the instances you really want,
by traversing them and call a matcher/filter function. Performance is a
secondary issue.

though fewer than the number of
embedded SQL statements that would exist if I did not put them behind
an interface.

What is the purpose with putting a statement like "select salary from
employee where SSN=?" behind an interface? You are substituting one
one-liner with another one-liner that needs an additional
implementation.

Why do you want to hide predicate
logic and set operations behind a procedural interface?

I don't. I want to give the operations meaningful names. For example:

findEmployeesEligibleForRetirement

This is neither predicate logic nor a set operation. You have given an
example of a function, which indeed is very useful (also together with
predicates).

is more evocative than a long SQL statement that doesn't mention
retirement at all. Think of the functions as compilable comments that
describe what the SQL beneath them is intended to do.

A much better idea would be to create a view
EmployeesEligibleForRetirement. Views are much more flexible than
functions, because they can be combined together in other set
operations and logic statements. You might for example join this view
with the SalarayPayment relation. If you embedd the statement inside a
function, you don't have that kind of flexibility.

This has the additional benefit that when the eligibility rules change,
the callers of findEmployeeEligibleForRetirement() will be unaffected.

The same benefit exists if you create a view.

In any application, OO or not, this translation must take place.

Absolutely not.

The data is on the disk.

This is a common statement from people that lacks education about
modern databases. They think that the SQL statement
"select mycol from mytable", will cause the database to read something
from disk. In a well-tuned database, the data will most likely already
be in RAM.

It must be translated into some kind of
TableRow structure or similar. Then it must be unpacked from that
structure into something convenient for the application to use.

Now it is entirely possible that the application will simply index into
the TableRow structure every time it wants to access the data; but even
that is an *implicit* translation into a more convenient form.

You don't need a TableRow instance, just use select/fetch into. And if
you still prefer a result set, this class is generic. You don't have to
write it yourself.

If you have a table employee and a class employee, you obviously have
duplication.
You have the same "duplication" if you have a table "employee", and a
set of convenient variables used to hold parts of one of the rows from
time to time. You even have it if you have a TableRow structure that
holds the employee row.

TableRow is a generic class, employee is not.

If you have five variants of getEmployeeBySomeCriteria,
you obviously have duplication.
I don't see that at all. The five functions may simply call a more
general function passing in specific parameters.

Why do you want the five functions in the first place? If you have
general function, why not use that one from the beginning?

Fredrik Bertilsson
http://mybase.sf.net

.