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.

Who would do a dumb-ass thing like that? Sorry for the vulgarity but...

When I encounter this type of implementations, the main reason is
because they want to limit the number of getEmployeeBySomeCriteria
methods. Another reason is because they want to work with an objects
graphs instead of relational calculus.

No, of course I would use the database to fetch the data I want. I'd
make sure that a well structure SQL statement was used against a
well-normalized database. Who wouldn't?

You claim that it is possible to only have a few number of
getEmployeeBySomeCriteria methods with optimized SQL statements for
every different way you might need to fetch employee data? That should
only be possible for rather small applications.

Then I would hide that SQL statement behind an interface so that the
rest of my application was unaware of it.

And the benifits are?

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.Consider this:

Select employee_number from employee where date_of_birth < 1952 and sex
= F and employment_type = EXEMPT OR emloyment_type = SPECIAL and salary > 90000;
I'd like to hide this behind:

find_all_employees_eligible_for_early_retirement();

This should obviously be a view. After creating that view you might use
it in other queries.
select date, amount from payment p join
employee_eligible_for_early_retirement e on p.id=e.id

Your solution would cause extra roundtrips to the database for fetching
the same data.

Firstly, it makes the program easier to understand. Secondly, it
isolates the policy from the implementation. I can change the
implementaiton of the SQL statement without affecting the functions
that call find_all_employees...

A view would have the same benefits.

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.

Why do you ignore the existance of views?

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.
Agreed. However, it is not a "much better idea" it is a better way of
*implementing* the original idea. My aplication still needs the
function.

Your application does not need the function. Just call
select * from employee_eligible_for_early_retirement

It must be translated into some kind of
TableRow structure or similar.
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.
Great! Then I can pass the convenient data structure around my
application just like an object. How convenient!

There is no need for passing data structures around the application.
Relations are the only needed data structures. (Sometings performance
issues might force you to use low-level collection classes likes arrays
and hastables, but this is normally not the fact for business
applications.) The application should ask the database for the needed
data, using set theory and predicates, when the data is needed, not
before.

Fredrik Bertilsson
http://mybase.sf.net

.

Relevant Pages

  • Re: ADP Help
    ... employee selection form, selecting a single employee from the combo box, ... SQL statements are on the SQL Server, how would the SQL statement know how ... I use that query as a base query ... >> Randel Bjorkquist ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Boochs book feels too philosophical rather than practical?
    ... OO allows you to add new data structures ... It talks about different types of payment classifications. ... This allows an Employee object to hold a referent to a paymentClassification object. ... Just list the taxonomies in outline format: ...
    (comp.object)
  • Re: Boochs book feels too philosophical rather than practical?
    ... OO allows you to add new data structures ... OO approach locks you into mutual-exclusiveness. ... If the employee falls into a category ... Just list the taxonomies in outline format: ...
    (comp.object)
  • Re: Critique of Robert C. Martins "Agile Principles, Patterns, and Practices"
    ... SSN, by department, by city.... ... I'd make sure that a well structure SQL statement was used against a well-normalized database. ... Then I would hide that SQL statement behind an interface so that the rest of my application was unaware of it. ... employee where SSN=?" ...
    (comp.object)
  • Side by Side Worksheet Functions
    ... you may post some example data (if both data structures ... >I have 2 long user info extracts which I need to compare ... an HR database. ... or registered (new employee not ...
    (microsoft.public.excel.worksheet.functions)