Re: OOP - a question about database access

"Bob Badour" <bbadour_at_golden.net> wrote:

> "Universe" <universe_at_covad.net> wrote in message

> > "Bob Badour" <bbadour_at_golden.net> wrote:

> > > "Universe" <universe_at_covad.net> wrote:

> > > > "Bob Badour" <bbadour_at_golden.net> wrote in message

> > > > > "Alfredo Novoa" <alfredo_at_ncs.es> wrote in message

> > > > > "Alfredo Novoa" <alfredo_at_ncs.es> wrote:
> > > > > > > >Objects like Employee, Customer, etc are completely
unnecessary
> > > > > > > >because that entities are already managed by the DBMS.
You only need
> > > > > > > >to map the database tables to visual controls like grids,
edits, etc.

> > > > > > "Robert C. Martin" <u.n.c.l.e.b.o.b_at_objectmentor.com> wrote: > > > > > > > This might be true if the database application does absolutely not
> > > > > > > processing of the data. If there are no business rules, and the
> > > > > > > system does nothing more than add, display, modify, and delete
> > > > > > > records, then having entity objects may not be very useful. On the
> > > > > > > other hand, as soon as you add any business rules, such as field
> > > > > > > validation, or summary reporting, etc. you need a way to separate
> > > > > > > those rules from the database. That's one very useful application for
> > > > > > > OO.

> > > > > > What a pearl!
> > > > > > ...
> > > > > > If recognized OO writers show this "understanding" of the

> > > > ... *please* explain *concretely* why an app that processes *outside* of the
> > > > dbms would not use separate types?

> > > Please explain how your demand has anything to do with what I wrote.

> > Not a demand, simply a request [note the *"please"*] in quest of > > furthering discussion to extend and deepen truth.

> I took the emphasis as sarcasm. If that is not what you intended, why did
> you choose the emphasis you chose?

> > > > ... *please* explain *concretely* why an app that processes *outside* of the
> > > > dbms would not use separate types?

Of what the "concretely" and "outside"? For clarity not sarcasm. I wanted to make clear I was asking why Novoa and whomever agreed didn't see validity, the usefulness and even requirement - as RCM pointed out wrt processing external to the dbms - for the types created in addition and external to the dbms types.

> > > > Can you guys explain why OO's support for polymorphism is bad, or not
> > > > useful?

> > > Why would I explain anything I never said? Can you explain why the sky is
> > > pink?

> > If you have never explicitly said that on comp.object, it was implicit
> > to me in your explicit comments.

> I do not make implicit statements.

To my logic you did.

> Please confine your criticism or analysis to what I actually write or say.

I will make criticism of whatever I find requires criticism. If you disagree with how I see the implication state it, remain silent, or make more silly statements.

> Otherwise, you are arguing with your own imagination, which is nothing more than intellectual
> masturbation.

Most prefer "stating it". But again I will speak to whatever *I* find relevant. Hey and if its "self-gratifying", then all's the better.   :- }

> > If you don't agree, c'est la vie. Your loss not ours.

> How do I lose anything from not accepting the thoughts you incorrectly > attribute to me?

I was speaking about your disdain/dislike/anti-OO in general.

After almost a decade and a half of OO practice, 4 published OO works - i) polymorphism, ii) layered system architecture, iii) philosophy wrt OO and sw engineering generally iv) OO high level design - in magazines and books, I can discern what's anti-OO fairly well.

> > > I encourage the use of the relational model, and I have > > > never disdained it. If you are suggesting that some primitive location-based
> > > computational model has usability advantages, please show us your empirical
> > > evidence.

> > There are few formal analyses that OO modelling is less complex and more
> > intuitive.

> That makes sense given it is much more complex and far less intuitive. For
> most and very probably all developers, it is very much an acquired skill.

No. Just a matter that the greatest benefit of OO is not "quantitative" or "metrical", but "qualitative" and "cognitive". Much harder to create empirical proof. But there are studies where for the same context that the average project posses, OO proved itself superior. See Caper-Jones for one set.

> > However the empirical evidence that most advanced developers and IS/IT

> > savvy clients generally find OO models more intuitive, and or less
> > complex than models of other paradigms for the same given context is
> > that they communicate this understanding.

> Expert developers understand and use OO--not because it is intuitive but
> because they trained very hard for an extended time in order to understand
> it. Even still, few of them understand it well enough to recognize its > limitations or its essential nature.

You can *prove* that? Seems you think that OO is "some primitive location-based
computational model". Some day I'd like to read your definition of "location-based
computational model". That term is in none of my CS/IS textbooks, none of the books in the CS/IS section of the bookstores, and in none of the various industry periodicals I read weekly and monthly. Plus that is one supposed limitation. Perhaps some day I'll read the others you allege regarding OO.

> I do not disparage OO. I disparage the cognitive box from which you view the
> world.

My prime cognitive box for sw engineering is OO. ???

> Who is in a better position to know my mind? You have > nothing to offer me in that regard.

That's what *you* think. That is because you either you don't agree with or don't understand the implications of things and processes in the world existing independently of whether or not, or how, one or more may think of those things and processes. I.e. there are things that are true you are not aware in spite if you agree with that or not. I'll say what I think is best to support genuine truth, what you do about is what you do. Killfile me. Again your loss. Sure you'll do and it and fantasize no loss. All the more misthinking you'll experience.

Elliott

-- 
Though types are contextually based, they are **objectively true** for
the context.
-- 
Be bold, be artistically imaginative, yet scientifically grounded -- DO
GREAT  OO  MODELLING  WITH  OBJECTS  OF  ALL  TYPES!!
-- 
                      *~* Theory Leads, Practice Verifies *~*
     *~*  Global Plans + IID (Iterative & Incremental Development) *~*