Re: Relational-to-OOP Tax

"frebe" <frebe73@xxxxxxxxx> writes:
Please try to read the arguments presented to you. You ask for
supporting argumentation, but when presented to you, you simply
ignore it.

Nothing in that post proves his claim. The closest you come
is saying that shorter code is simpler.

So, you agree that decoupling SQL statements from the rest of the
applications causes more bloated code?

Since you're so fond of accusing others, baselessly, of playing
word games, I will point out that your use of the term "bloated" is
pejorative. Based on your posting history, I believe it to be
deliberately so.

Decoupling SQL statements may or may not increase the total
number of lines of code, depending on the size of the SQL statements
and the number of times they are reused.

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.

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.
Reliability is increased when code is designed to be easily testable,
another characteristic of clean code. Horizontal and vertical
scalability benefits from having clearly defined, decoupled
components. Security is easier to implement and prove when components
have single responsibilities.

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

The benefits of decoupling SQL has to be considered unknown until
someone can prove them. But the disadvantages (more bloated code)
are easy to prove and has to be accepted as facts.

The benefits are readily apparent to anyone who has developed any
large, or even mid-sized, enterprise system. The "bloat" you claim
has yet to be demonstrated when comparing like with like rather than
your naive lines of code metric.

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