Re: Relational-to-OOP Tax


Patrick May wrote:
"frebe" <frebe73@xxxxxxxxx> writes:
As discussed elsewhere in the thread, even the hard of learning
Mr. Jacobs admits that lines of code is not a sufficient
measure.

More lines of code takes longer time to write. More lines of code
makes the code harder to read.

This is not always, or even often, the case. Highly coupled
big balls of mud that mix different concerns are more difficult to
understand than well-factored, clean code.

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

Actually, several people have pointed out the value of separating
concerns. The retrieval, transformation, and use of data are
conceptually different; combining them in a single lexical unit
reduces the understandability of that unit.

"Understandability" is different per person. Individual's brains are
different due to recombinant DNA. What throws off one person does not
throw off another, and visa versa. Your argument is essentially a
pyschological one, not really a logical, imperical one. Now, if
wrapping works for you, that is fine by me. It is the universal
extrapolation that bothers me. The necessary extrapolation to every
developer is what you have not demonstrated.


The techniques used to decouple components and avoid big balls
of mud offer significant benefits, particularly in addressing
non-functional requirements.

Can you prove this claim?

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)

Even in this simple example, the name of the function is more
descriptive than the SQL statement. It can also be re-used without
exposing the database schema throughout the application.

Personally, I would often prefer an inline comment. Too many nitty
gritty methods/functions makes it harder for me to find and read the
"real" functions. Too many croutons makes it hard to find the meat.

And it creates the need to change two named units instead of one, as
already described. That is objectively more work. If you follow hand
and eye movements, you will see it takes longer to visit and change
both.

http://en.wikipedia.org/wiki/Time_and_motion_study


Reliability is increased when code is designed to be easily
testable, another characteristic of clean code.

Doesn't the SQL statements need to be tested too?

Of course. Isolating it from the application functionality makes
it easier to test both in isolation.


You haven't demonstrated a need to test them in isolation. Often
testing them together is fine.

Horizontal and vertical scalability benefits from having clearly
defined, decoupled components.

The decoupling you are talkning about is only about creating extra
layer inside an existing process. How can scalability benefit from
this?

Not at all. I'm discussing decoupling in the general sense, of
which encapsulating SQL is only one, albeit important, aspect. Both
horizontal and vertical scalability benefit from the existence of
decoupled, well-encapsulated components.

It *increases* coupling by having a function (wrapped SQL) that is
tightly coupled to the calling routine. It is a one-off function.


Security is easier to implement and prove when components have
single responsibilities.

Do you have some examples of this?

One of the primary difficulties with implementing security
correctly is the difficult to understand interactions between complex
components. Having a single responsibility for each component
simplifies analysis and testing considerably.

I think he meant code.


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.

In general, I agree. However, failing to isolate concerns does
not result in clean code, either.

Then how come you don't do this:

function addFooAndBar(foo, bar) {
return(foo + bar);
}
....
x = addFooAndBar(foo, bar);
....

Instead of

x = foo + bar;


The "bloat" you claim has yet to be demonstrated when comparing
like with like rather than your naive lines of code metric.

If the bloat if obvious in a very small example, why wouldn't it be
obvious in a larger application?

Small examples tend to focus on the implementation of the
technique, resulting in larger perceived overhead. In a larger
application, the benefits of certain techniques become more apparent.

More appearent everywhere except here. If you split your code into
relatively independent smallish tasks or apps, then there is no "big
application". Perhaps you or your paradigm are poor at partitioning.
Divide-and-Conquer. I've seen a top 5 company in size do just that
using procedural/relational. Maybe you really do need all that
buerocracy in your code if you create a giant ball of classes and the
Mother of All EXE's.


Sincerely,

Patrick


-T-

.

Relevant Pages

  • Re: Relational-to-OOP Tax
    ... Clean code is easier to maintain and extend. ... Doesn't the SQL statements need to be tested too? ... Isolating it from the application functionality makes ... The decoupling you are talkning about is only about creating extra ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... Forcing all SQL statements into functions instead of only putting them ... cleaner or more well-factored code. ... Clean code is easier to maintain and extend. ... The decoupling you are talkning about is only about creating extra ...
    (comp.object)
  • Re: Export Excel
    ... > parameters appearing in the address bar, ... > MSIE is showing the string in the title because You aren't using a ... > Use POST to submit Your string, and the address bar remains clear. ... > Do I have to tell You that submitting and executing full SQL statements ...
    (comp.lang.php)