Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: Robert Martin <unclebob@xxxxxxxxxxxxxxxx>
- Date: Tue, 23 Jan 2007 16:59:07 -0600
On 2007-01-23 13:25:22 -0600, frebe73@xxxxxxxxx said:
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.
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, though fewer than the number of embedded SQL statements that would exist if I did not put them behind an interface.
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()
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.
This has the additional benefit that when the eligibility rules change, the callers of findEmployeeEligibleForRetirement() will be unaffected.
In any application, OO or not, this translation must take place.
Absolutely not.
The data is on the disk. 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.
There is no duplication. There is no waste.
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.
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.
--
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716 |
.
- Follow-Ups:
- References:
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: JXStern
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: topmind
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: Robert Martin
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: topmind
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: Robert Martin
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: frebe73
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- Prev by Date: Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- Next by Date: Re: Booch's book feels too philosophical rather than practical?
- Previous by thread: Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- Next by thread: Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- Index(es):
Relevant Pages
|