Re: too much OOP ?

On Jan 2, 11:13 am, "Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx>
wrote:
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.)

If we don't share your view that the abstraction level is determined
by the "remoteness", the rest of your post is rather meaningless.
Assembler is pretty "remote" from the problem domain payroll
processing, but that doesn't make it very high level.

I know that there are no really objective ways of determinate the
"level of abstraction", but most IT professionals would agree that SQL
is an 4GL and most OO programming languages like Java, C++, etc, are
3GL. Most IT professionals would also agree that 4G languages could be
considered as having an "higher level of abstraction" than 3G
languages.

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.

//frebe
.

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: 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)
  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)
  • Re: object system...
    ... what the C compiler typically produces... ... C++ is a versatile language, as one can use it in some places mostly like it ... in general, this compiler provided abstraction, will somewhat beat out the ... but I still don't see how this relates to "programming based on ...
    (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)
Loading