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

"Craig Shearer" <craig.shearer_at_no_spam_please_bigfoot.com> wrote in message news:<3b9c3fa0_at_clear.net.nz>...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:obVk7.770$Vc4.134525028_at_radon.golden.net...
> > >
> > >If you're asking about Integrity Checking, then there is no formal
> mechanism
> > >for defining this.
> >
> > This gives a huge advantage to the relational data model then, which does
> > have such a formal mechanism.
> >
>
> Let's compare correctly. I said that there was no formal mechanism for doing
> this in the example OODBMS that I was using (which happens to be JADE) but
> that doesn't mean that such a mechanism could not be implemented. It would
> be possible to implement this with as much formality as The Relational Data
> Model allows... not all OODBMS products have matured this far, yet.

Since the relational model already specifies the interface to an OODBMS that has this formality, why would anyone want to use a non-relational dbms?

The network model on which the non-relational dbmses are based does not have any real formality. The formality of the relational data model arose in its very conception. As far as I have seen, nobody has proposed an alternate formal system yet. At best, all competing data models have tried to describe an ad hoc model using formal techniques.

In short, when oodbms products have matured to the point where they do have such a formal mechanism, I expect you will find they are rdbms products.

> > >However, it is possible to define code in the destructor
> > >for the class that would raise an exception under certain circumstances,
> > >thus preventing deletion by forcing the transaction to abort.
> >
> > Since the DBMS must support multiple applications and multiple programming
> > environments, what prevents your Java programmers from omitting an
> important
> > constraint in the destructor that your Smalltalk programmers rely on?
> >
>
> But this particular DBMS is active - you can't get at JUST the data, you
> necessarily invoke methods too.

Nothing prevents someone from writing a new method that violates the existing integrity constraints as implemented in other methods.

> If another language wants to delete a JADE
> object, then the JADE destructor will be invoked - you can't program around
> this!

In JADE, it is perhaps possible to code a cascaded delete. This barely scratches the surface of integrity enforcement. What prevents someone from writing a method that inserts an orphan?

What application programming languages does JADE support?

> Or, as you are so fond of saying, your original assumptions are false which
> renders the rest of your argument invalid. :-)

Perhaps. How many applications and application programming environments does JADE support?

> > >I'm not certain what you mean by symmetric references, but I'll hazard a
> > >guess. When references between classes are defined, you specify an update
> > >mode - effectively which side is manually maintained. So, if the
> > >relationship defines manual on one side and automatic on the other, then
> the
> > >compiler will reject (with a syntax error) code attempting to update the
> > >automatic side of the relationship. It is possible, though, to define
> both
> > >sides as manual/automatic, meaning that whichever side is maintained
> > >manually, the other side will be automatically maintained.
> >
> > Symmetric means the user can use the value as to identify referencers as
> > easily as the referenced. All of the above manual and automatic crap are
> > just more physical implementation details forced on users.
> >
> >
>
> Then by your definition, these references are symmetrical.

Really? I can access the instances of any object class without navigating through instances of other object classes? I can insert new order items into an order without specifically accessing an instance of the order class?

> Regarding the manual/automatic thing, I don't believe this to be a physical
> detail - my opinion is that this represents something logically inherent in
> the data.

Navigation is not inherent in the data. Whether the user establishes a valid relationship by changing one entity or the other entity is irrelevant to the data. In the end, the user should determine which is appropriate to the application at hand provided the resulting relationship is valid.

> But then your reaction to anything that The Relational Data Model
> doesn't implement seems to be that it's an evil physical implementation
> detail.

The relational data model specifies a logical data model. Implementation is a totally independent issue.

Requiring the user to know which of two pointers he or she can change forces users to deal with irrelevant details. The relational model does allow (and even requires) symmetric relationships among data -- in fact, that is one of its fundamental uses!

Implying that the relational model does not allow relationships among data is ludicrous. Received on Mon Sep 10 2001 - 23:20:56 CEST