Re: Relational-to-OOP Tax


Thomas Gagne wrote:
frebe wrote:

But nobody have proved why separating all SQL statements would create
cleaner or more well-factored code.

You keep asking for proof without specifying the burden of proof. What
burden of proof would require for structured programming to prove it is
better to call functions than not to (as used to be the case) or that it
is better to let a filesystem handle file-io than an application to
manipulate disk structures directly (as also used to be the case)? Is
the burden of proof really so different that you can't extrapolate your
experiences calling functions or using open/read/write/close to
manipulate files onto SQL?

<snip>
Maintainability and extensibility are two NFRs that come
immediately to mind. Clean code is easier to maintain and extend.


In what what way is

createEmployee(x,y,z)

function createEmployee(x,y,z) {
insert into employee values (x,y,z)
}

cleaner than

insert into employee values (x,y,z)

It is cleaner when createEmployee(x,y,z) is more realistically imagined:

insert into employee...
insert into address ...
insert into employeeAddress ...
insert into employeeEmployee ...
insert into calendarResource ...
insert into payroll ...
insert into planParticipant ...
insert into benefitParticipant ...
insert into dependents ...

and when another table is created that must know about new employees the
procedure can be updated without modifying application code. Or if
employees can be added from multiple applications it is better to have
isolated the code for adding them than to duplicate it.

In that case I would agree, but because it is an *entire* task in
itself, not just part of a task. But that is not the typical use of
SQL.

Plus, it is a bit of a suspicious design. In most cases there are CRUD
screens to enter each of those *one* at a time. It is not common do
update multiple entities like that all in one shot. First you create
the Employee record and then press Save, then Benefit records and
press Save, etc. One or two entities per CRUD screen is the norm.
Nine is a freak. I suspect you are storing everything in OO
structures first, which is unnecessary.

<snip>
Are you arguing that clean, well-designed code does not have
quality benefits?


No, but creating new functions with only one statement or functions
that are only called only once, doesn't create cleaner or more well-
designed code.

Practically speaking that is rarely the case. And even if it occurred
more often than rarely, it is a better design that allows one
module/function/method to change independently of others that rely on it.

I bet I could find counter scenarios for any scenario you present.
Changes come from all directions, not just from pro-OO books.


--

-T-

.