Re: too much OOP ?

On Tue, 1 Jan 2008 07:41:53 -0800 (PST), Daniel T. wrote:

On Dec 28 2007, 12:20 pm, "Dmitry A. Kazakov" <mail...@dmitry-
kazakov.de> wrote:
On Fri, 28 Dec 2007 09:26:27 -0500, Daniel T. wrote:
Matthew Shelton <crash...@xxxxxxxxx> wrote:

I'm building a java/JSP webapp. So I have everything designed
pretty well, expecting usual code/test iterations.

I'm just wondering if OOP is a bit overkill for a database app.
I continue to end up with a utility class with a bunch of
static methods, no matter how I try to analyze it. as
everything is done one record at a time (inserts, searches,
updates.) so I don't really have a need for multiple instances
of a class. It seems pretty procedural, by nature.

Unlike the last responder, I have to say that it may very well be
the case that OO isn't appropriate for your application.

I don't think it is true, or better to say, it is true only because
these systems are designed at an extremely low abstraction level.
When the OP talks about "update query" it is an indicator of.
Another is "database application." Not uncommon, but it is actually
same as to talk about a "CPU application" and then to conclude that
there isn't much OO around "MOV" instructions. True, so what?
Should it be this way?

I hate to sound like I agree with topmind, and I have to admit that I
know almost nothing of the domain, but it seems to me that SQL is
pretty high level language in its own right.

I think you make the same logical error as he does.

What an SQL request does is no matter, it could be extremely complex when
translated into assembly instructions or considered on the level of
transistors and ferromagnetic materials. We just do not care so long it
does the work.

Important is only relation to the problem domain. (Thus Turing completeness
is also not an issue.) Regarding the domain, the abstracton level is in my
view determined by *remoteness* of solutions from concrete problems. This
is why all application-domain oriented languages are very low-level just
per their *intent*. They aren't remote, they just directly do what you
want. (Provided, that updating records is the problem.)

This is not an abstraction. Abstraction happened long before when a
language designer made a decision to abstract "update query" as a language
construct, not me nor you. Of course, there is nothing wrong with that as
long as we stay close to the domain of intent. Just let's call things by
their names.

Now, I wouldn't claim that I understand much "biz", but I guess that many
application there are much more than "updating records." In that case SQL
would necessarily become higher level than it was originally intended, and
so the question arises whether it has enough abstraction power to cope with
that. We all (including topmind) know that it does not. We also know that
there cannot be a universal problem-oriented language. Once you start to
specialize anything that thing will loose its universality.

OO is merely an attempt to address this sort of problems.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: too much OOP ?
    ... If you can look into UPDATE and see MOV there, ... abstraction has something to do with "black boxes". ... Many SQL dialects are Turing-complete. ... specialized language. ...
    (comp.object)
  • Re: too much OOP ?
    ... if you managed to solve the problem in Assembler and if the ... Consider topmind's wrong claim that SQL is ... makes no sense to talk about *immanent* abstraction levels of the ... To the program or to the language of? ...
    (comp.object)
  • Re: too much OOP ?
    ... know almost nothing of the domain, but it seems to me that SQL is ... pretty high level language in its own right. ... view determined by *remoteness* of solutions from concrete problems. ... If we don't share your view that the abstraction level is determined ...
    (comp.object)
  • Re: Generating SQL
    ... >> builds strings in another language for some other compiler to parse? ... > Abstraction is horrible? ... > SQL translator. ...
    (comp.object)
  • Re: object system...
    ... for that you need machine language. ... But the price of abstraction is performance. ... involves the function call overhead, the cost of copying the structs around on the stack, much less efficiently crafted ASM output (since the compiler may lack most of the context from the caller), ... ... But because of the 3GL type system compromises the way one must do that is with a different mindset towards design, not OOPL programming. ...
    (comp.object)
Loading