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

On Wed, 25 Jul 2001 23:05:26 -0700, Lee Fesperman <firstsql_at_ix.netcom.com> wrote:

>akmal _at_ city wrote:
>> On Mon, 23 Jul 2001, Lee Fesperman wrote:
>> > akmal _at_ city wrote:
>> > > On Mon, 23 Jul 2001, Jim Melton wrote:
>> > > > Your statement is false because there is no commercially available database
>> > > > today that can achieve the real-world performance of (most, many, all?)
>> > > > object databases.
>> > >
>> > > For what kind of applications? (most, many, all?)
>> > >
>> > I must say that was quite an overreaching statement. It apparently includes operations
>> > where object databases clearly perform poorly --- like ad-hoc queries.
>> >
>> I agree. Even in cases where an application has been "objectified", there
>> may not be any significant performance gain provided by an OODB. Example:
>>
>> ...
>
>Actually, I didn't want to turn up the flame wars, but that one was particularly
>egregious.
>
>OO *is* better than the previous generally used method of creating software, but it is
>hardly a panacea. It's fine for modeling software artifacts, especially when compared to
>what went before. However, its capability in modeling the real world is weak (see, for
>instance, C. J. Date's article on Debunkings --
>http://www.firstsql.com/dbdebunk/cjd8a.htm).
>
I read C.J. Date's article. I am at a loss how you draw the conclusion that the capability of OO to model the real world is weak from that article.

The article is basically a design argument on how to factor geometric abstractions in an inheritance hierarchy (symmetrical/asymmetrical). Truth be known, graphics programmers resolved these issues over a decade ago. Why Date would chose this as a "Debunking" issue for Databases is curious. Maybe it's a navel-staring excercise on the theory of programming constraints or something (which is what got Stroustrup in an tiz).

>In all the OO systems I've seen, everything is built with single direction linking -
>(pointers, references, composite objects). Inheritance is even worse; it is purely
>hierachical.
>
 

>That's fine for programmers who are used to it and don't have any better tools anyway,
>but a non-programmer wants to get from customer to invoice or from invoice to customer
>without having to know you must a different link/technique/concept for one direction
>versus the other.
>
>I started programming in the '60s and don't see any ideas in OO that weren't known then.
>Combining data and behavior was possible with Forth in the '60s.

Agreed. (Same is true for Fortran.) Maybe the problem here is not so much between code and data (objects), but programming languages and Databases.

My point being that the data in a Database is often used by *multiple* programs written in a variety of programming languages. Consequently the context of "data" in a shared repository (Database) has a different (and larger) set of design factors than "data" encapsulated in a single application object instance (program).

Regards;

Bill Cole
JumpStart Systems Received on Fri Jul 27 2001 - 00:11:52 CEST