Re: Clean Object Class Design -- What is it?

> True. It is a personal opinion; albeit, based on extensive experience. The
> best that I've ever seen anyone strive for is a class model that supports an
> extremely limited subset of the potential applications.

Well, some OO people do real data modelling, they might use common OO idioms in analysing the problem, but you can use good OOA techniques and then validate your data model from a relational perspective .

But after you have a data model, you still don't have an application, much less the tons of diverse applications that your relational model is constructed to support.
So now you enter the realm of CLIENT APPLICATION space, where the relational model all by itself is not applicable.

> >As a matter of fact, a quasi-majority of business systems are
> >programmed nowadays in some kind of OO language on the client side,
> >or on the middle-tier side, while they certainly don't suffer from
> >what you have accused.
>
> In this case, you have further limited the scope to less than a single
> application. Now a given object class schema is limited to a single tier of
> an application partitioned across multiple tiers. I am confused. Are you
> trying to demonstrate my point?

No, it's simple, see above. You have to have a class schema, to do a particular application in OOP, or you can choose procedural approaches, or functional, or constraint based programming.
But the relational model just doesn't address how you construct your application, therefore any polemic on the subject as how do I do my application outside the database is futile.

> >This relational VS OO fight is quite misguide IMHO, but this is true
> >on both sides of the story.
>
> First, we have to get the OODB proponents to realize what their proposal
> really is. In almost all cases, they propose a network model database with
> domain support.
>
> In the end, it's the OODB vs. relational fight that is misguided since
> relational is already OO.

Well, I doubt that you (or C.J. Date ) can say that the relational model is already OO , since you don't know what OO is. As a matter of fact you can't know what OO is, you could be more permeable to other's ideas and find out about several sound OO models, if you take the effort to study them.

It may be that the relational model is already "OO", strictly in the sense that ODBMS proponents want "OO" to be.

The way I (and many others ) see it, OOP and Database Theory address totally separate concerns.
They are perfectly complementary to each other. And when people forget about this, you have a lot of confusion.

>
> >> >The two camps seldom are talking about the same language or correctly
> >> >understanding each others' terms.
> >>
> >> While I realize that very few object oriented programmers have any
 knowledge
> >> of the relational model, I have been very impressed by the depth of
> >> understanding of object oriented concepts displayed by relational
> >> proponents.
> >>
> >> Quite frankly, Chris Date and Hugh Darwen are the first people I have
 ever
> >> seen who made any attempt to use any kind of precise definitions in the
> >> discussion of object oriented systems.
> >
> >Quite frankly, being an admirer of Date and Darwen, and feeling quite
> >unbiased after being "shot at" from both sides, I can safely say they
> >have a rather weak understanding of OO technologies as they are used today.
>
> That's a rather astounding statement. On what do you base it?

Well, it's enough to look no further than the references they cite on OO issues. To their credit, it is difficult enough if you;re from outside OOP to find your way through lots of successful but rather poor OO literature, much the same as I found difficult to find my way to through lots of books that claim they address Database Theory or Database Design. After you study several OO models (let's say you can start with "The C++ Programming Language", or "The BETA Programming Language" as good examples)  you'll see how easily they fail to address the issues that OO is trying to address.
Anyway they can't possibly address those issues, unless they move outside the database realm, and then there you'd have an effort to find an all unfying approach to building information systems, which woulkd really be futile.

> >The main misunderstanding is that they think there's only one
> >OO model, or even it can eventually be only one OO model, and trying
> >to come up with that "THE OO model" themselves.
>
> Actually, they would be the first to say that the OO people cannot even
> agree on what OO really is. I fail to see how that is a misunderstanding on
> their part.

Nobody in his right mind would try to agree on "what OO really is". I told you there are several equally sound OO approaches , models ,etc.

How's that if we try to agree to a common unifying approach with regards to all the cultures of the world, and construct an unifying literature?. Or what if we try to agree to a common model for all programming languages wiping the differences between structured, OO, and functional programming. It would be futile , woudn't it ?
The same as with the "What OO really is ?" type of questions.

> Since they are database experts addressing issues in the database field, why
> do you think they should address anything other than OODBMS?

It looks to me they chase dead horses.
What is an OODBMS , and is it really a database ? They address only the hype created around OODBMS.

> >They are of course right on their polemics, but they miss the real
> >target (OO programming), if there's even a need to have such thing
> >as a target,
>
> The whole point is OO programming is not their target. As far as I am
> concerned, anything goes in the application programming arena. If you need
> to code in assembly, then by all means code in assembly.

Well, I could as easily code in a "relational language", except there is none, and "Tutorial D" already looks rather bad.

> Their only interest in programming languages is in the area of addressing
> impedance mismatch. They have claimed we should raise the level of the
> programming languages to the level of the database rather than cripple the
> database down to the level of the programming languages. I tend to agree.

"cripple the database down to the level of the programming languages." ???

Well, that is one really stupid remark. You're comparing apples and oranges and say you don't want to criple apples down to the level of oranges ??
That's the superficality you commonly find in people on one side or the other of this nonsensical debate.

There's no such thing as "impedance mismatch" in my view. There are some very opinionated OO people that think in this terms, but you can't blame "OO" in general much more than I can blame relational theory for what SQL people think about allowing duplicates.

>>Really, so it follows that relational people are generally smart while
>>OO people are generally kind of stupid ...
>
> I don't see where you can draw that conclusion from my statement. It seems a
> little non sequitur.

Well, from your statement I can imply that OO people are generally misguided - they adress the wrong problems.
We should try to cease talking about categories, and talk about individuals (individual people, individual ideas or theories).

> >So, in the end, there's NO definition of clean OO design (or class design)
> >out of context, because while we might talk of only one relational model,
> >there are a several OO models under the sun.
> >
> >However, I haven't heard this notion of "clean object class design" in
> >any OO model that I know of, so probably it's only a "metaphore".
> >You have to ask the guy who wrote such a thing and maybe share what you've
> >found. If he/she gives you a precise definition then you should look at
> >it rather suspiciously.
>
> Well, this thread did ask the question and he did not answer it.

The question itself is rather futile. I believ some people answered with some qualities recognizable in an OO design. It really depends what particular OO model we're talking about. Some of the qualities are more general and apply to several models.

> >On the oher hand the real issue is that denormalization
> >is hardly THE only way to achieve a fully normalized and
> >well thought database design, and as a method I find it
> >awkward to say the least.
>
> I can emphatically say that normalization, on its own, cannot possibly lead
> to a well thought database design. However, I do not think one can really
> claim that a design that was never normalized is well thought.

Well, isn't this the single most glaring mistake C.J. Date makes in "Introduction to Database Systems" the chapter on database design ?

By the way, you don't need to normalize something that you reach through an alternative database design method and you can prove it is already normalized.

There are other subtle issues as well with their approach in "The 3rd Manifesto", but they would rather keep themselves in seclusion (read ivory tower), so not everything is clear and bright on the relational side as well as on OO sides, "loosely speaking" as there really are no sides here.

You could also contribute to a better understanding by lowering the tone about OO in general, and if you try to understand the other's view, you can find better and more meaningful replies.

Regards,
Costin Received on Sun Jul 22 2001 - 01:33:35 CEST