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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:LyF17.4173$NL.80218263_at_radon.golden.net...
> >It was a toy example. Here's the abstract version, substitute whatever
> >worthy real-world objects you'd like in there:
> >
> >abstract class A
> >{
> > domainType1 x;
> > // operations follow
> >}
> >
> >class B extends A
> >{
> > ...
> > domainType2 y;
> > // operations follow
> >}
> >
> >class C extends A
> >{
> > domainType3 z;
> > // operations follow
> >}
> >
> >A very typical object-oriented programming pattern would be to have a
> >container containing objects of type B and C. We could iterate across
 that
> >container setting attribute x to values, without concern as to whether we
> >are dealing with an object of type B or type C.
>
> First, I would suggest you have not really encapsulated your objects, but
 in
> a relational system the only difference is you would use set-level
> operations instead of iterators.
>

It's encapsulated and extended quite properly. I deliberately made it abstract so that arguments about whether it had been encapsulated properly wouldn't be relevant.

"Set-level operations" have nothing to do with updating information. "Set-level operations" are: union, intersection, difference, etc. There's no "update" in there.

In the final analysis, the relational model accomplishes updates on sets by iterating across individual tuples in the set. Precisely the operation I described above.

>
> >How do we accomplish the same function using the relational model? Well,
> we
>
> In an SQL-like dialect:
>
> Update ContainingTable Set ColumnOfA.x = (SomeExpressionOfDomainType1)
> Where (SomeBooleanExpression)
>

This doesn't work, however, since there are no objects of type A, there are only objects of type B and type C.

>
> >can flatten the hierarchies (assume we find a primary key somewhere in
 the
> >objects, another complication of using relations with an OO model):
>
> Again, you are assuming one equates objects with tables or tuples when
> object classes are in fact domains. This renders the remainder of your
> example irrelevant -- it's a straw man.
>

I wasn't responding to you, but since you feel compelled to argue with me I'll repeat what I've told you before: In the real world where we actually have to implement applications, relvars == object classes. Deal with it. Received on Sun Jul 22 2001 - 01:34:25 CEST