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

>> >And by the way, from my OO 101 days, I believe one of the key attributes
 of
>> >an object is that it has identity.
>>
>> An object variable has identity, but then again so do all variables.
 Object
>> values are self-identifying, of course -- as are all values.
>>
>> If you are going to use the term "object" unqualified (ie. not object
 class,
>> object instance, object variable or object value), could you please
 define
>> the term? The term gets such sloppy usage that it eventually becomes
>> meaningless.
>
>Well, of course only an object instance can have identity.

Do you recognize any difference between an object instance and an object variable? If so, what?

>> >With the data
>> >copying inherent in all the relational systems of which I'm aware, how
 is
>> >this constraint maintained?
>>
>> I am not sure what copying you refer to. I am not aware of any copying
>> inherent to the logical data model; it would seem to me that copying is a
>> physical operation and not a logical operation.
>
>SELECT A.x, B.y from A, B WHERE A.key = B.key
>
>...There is nothing
>fundamental that allows traceability back to row 37 of table A that
 produced
>column x of row 7 in the result table. Data is copied and identity is lost.

Only because you projected away the key. Had you included it in your select statement, you would have preserved traceability and indentity.

In any case, I must challenge your statement that SQL databases invariably copy copious amounts of data, and I must further challenge your claim that this is inherent to the data model.

Both SqlBase and Oracle support a build-as-you-go style of fetching results and can also internally track result sets as lists of physical pointers.

Even object databases must "copy" data from the cache to the memory space of the application or from the server to the client. This is not inherent in the logical model but in the physical realities of computer architecture.

>> >You may counter that the alternative is exposing pointers to "users"
>>
>> I don't see how "identity" requires pointers when we have the option of
>> candidate keys.
>
>See above. We agreed that identical state (attribute values) does not mean
>identical objects. But now you are creating a constraint that all objects
 must
>have some field or combination of fields that is unique, meaning that two
>objects cannot have the same state.

Not true. Relations have some field or combination of fields that is unique. The relation then associates these fields with the other objects in the tuple. Relations definitively are not objects but definitively contain objects. The object variables, themselves, do not have any additional differentiating state.

>This is where the "arbitrary keys" that I
>mentioned in another thread come in.

Since the user must have some logical means of identifying the different object variables, the keys are neither arbitrary nor unecessary. Otherwise, two object variables with the same value become indistinguishable to the user thereby violating your requirement of identity.

>>> >if that "pointer" is no longer lived than the result table from a
 query,
 where's
>> >the harm?
>>
>> As just one example, it provides no way to refer back to your original
>> object from an excel spreadsheet.
>
>This problem is independent of relational/object.

Nope, I must disagree. Because the relational model uses values to identify variables, one can include the identifying values in the spreadsheet to reliably refer back to the data in the database.

>The difference is that an
>object-oriented application *can* keep a "pointer" to the original database
>object (or use it natively) so this association can be maintained.

You just changed assumptions mid-stride. Above, you required that the pointer is no longer lived than the result table from a query. If you are now suggesting that database pointers allow greater scope, visibility and persistence, all of the criticisms I have already posted apply, and all of the published criticisms of exposed pointers going back thirty years apply. Your example of the reorganization is just one example of a problematic situation.

Object-oriented applications, in general, do not keep pointers to the original database object but keep pointers to the copy of the database object in their own memory space. For those objects that do keep ODBMS identifiers, they can just as easily keep value-based keys as implementation-dependent, DBMS-specific OIDs.

Using value-based logical identifiers extends their usable scope and persistence far beyond the DBMS into other applications, media and systems.

>In a
>relational model, you must rely on artificial notions such as guaranteed
 unique
>key values to maintain linkage (put my query above into your Excel
 spreadsheet
>and tell me how you can update the original rows).

Straw man. You chose to exclude the identifying information. Choose to include it, instead.

Keys provide much more than just linkage. They provide informational identity as well as data identity. Received on Tue Jul 17 2001 - 18:22:56 CEST