Re: Relational-to-OOP Tax


Patrick May wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Patrick May wrote:


However, it logically follows that if you are using a relational
database, then designing the application close to it rather than
trying to wrap it away in OO classes and conventions will
simplify the design because one is not translating from one
paradigm to another.

If you're thinking of a CRUD system, then you're correct. For
any system with more complex behavior, you're going to need to
provide some support for that assertion. (I'm not holding my
breath.)

Show me typical complex behavior in a biz app that relational chokes
on.

Once again you've got it backward. You are the one making the
claim above. It is up to you to support it or retract it.

Above YOU implied that staying close to the DB was fine for "CRUD"
apps, but not for "more complex behavior". You agreed with me for
some situations but not others. Are you simply not challenging those
other situations, or are you claiming that being close to the RDBMS is
not helpful for "more complex behavior"? Yours is a half-ass claim.
Why mention "complex behavior" if it is not relavent to anything here?

And is Martin's an example of such? Let's focus on Martin's example
rather than your unicorn that allegedly stabs RDBMS with a complexity
knife. If you want to give an example of biz app complexity that F's
up RDBMS, please do. Until you do, I shall consider it a unicorn
claim. Perhaps you just don't know how to use RDBMS effectively. I
can't show you how to do it right unless I see it.

You appear to be more interesting in playing word games than
interested in figuring out why people say such and such is good.


I don't find your question coherent as stated. I frequently
use languages like Common Lisp and C++ that are considered
multiparadigm. Multiparadigm languages offer a great deal more
flexibility than more constrained languages like Java. Solutions
that are infeasible in a less flexible language become the most
elegant alternative when the appropriate constructs are available.

Perhaps, but that is not realistic for staffing purposes, per above.

I'm not sure what you're referring to "per above", but I haven't
had a huge amount of difficulty hiring developers experienced in more
than one set of techniques.

All this mixing paradigm stuff is irrelavent anyhow. Having more
paradigms inside does not *automatically* make something better, I
think you will agree. They have to be used effectively to make
something better. The issue here is Martin's style. Has Martin's
approach of translating between paradigms been affective? That is the
real question, not whether mixing paradigms is good in general.


[snipped links to past he-said-she-said fights. Nobody cares about
our old squabbles and it proved fruitless the last time we did it
because you think weird and interpret my writing in an odd way that
takes too long to correct, wasting time on nothing.]

In other words, I proved that point so thoroughly that even you
can't see how to squirm around it.

You wish. I simply don't want to play your word year-old word-games
again. It was a waste of time last time. I cannot change your evase
non-commital mind. The issue here is Martin's book, not what I said
years ago.

I didn't publish crap claims that bash relational, case statements, or
any other paradigm/technique, so the burden ain't on me. Martin hyped
OO, and I am simply asking for justification beyond "I like OO".


Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO

-T-

.