Re: Relational-to-OOP Tax

"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.

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.

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.

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.

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.

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.

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.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, middleware, SOA)
.

Relevant Pages

  • 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: Relational-to-OOP Tax
    ... Doesn't the SQL statements need to be tested too? ... You haven't demonstrated a need to test them in isolation. ... The decoupling you are talkning about is only about creating extra ... function addFooAndBar(foo, bar) { ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... you agree that decoupling SQL statements from the rest of the ... Clean code is easier to maintain and extend. ... But the disadvantages (more bloated code) ...
    (comp.object)