[cap-talk] a relationship is not an object
David Hopwood
david.hopwood at industrial-designers.co.uk
Thu Jul 5 11:32:17 EDT 2007
John Carlson wrote:
> A relationship is not a thing or an object. It's more like a having.
> I have a parent. I have a cat. I have a girlfriend. Any attempt
> at making a relationship a thing will fail, because it will have
> no identity.
So it can be represented as a functional object (in the sense of
<http://citeseer.ist.psu.edu/baker93equal.html>).
> Certainly you can enter a relationship into a database,
> but at that point, I believe it becomes a contract.
Or (represented as) a persistent functional object.
> Something
> written down about the relationship. Most relationships are
> non-contractual, or we throw the contract away. You have
> food to eat, but you don't keep the receipt from the grocery
> store stating your ownership of the food.
>
> Here's an example of a relationship that becomes a contract:
> There is a relationship between a part and an assembly
> such that the assembly has several parts that it is made up
> of. The contract is the drawing or model that you send to
> the supplier that says to put this part in this assembly. But
> the relationship between the part and the assembly doesn't
> really exist as a separate thing that you can grab ahold of.
In many (most?) 3D modelling programs, it absolutely does exist as
such -- both in the database schema and its implementation, and as
a user-manipulable object in the UI.
In a feature-based modeller such as SolidWorks, for example, these
relationships are called "mates", and there is a subwindow showing
all of the mates in the current assembly, and allowing their
properties to be independently edited. Incidentally, in this kind
of modeller, mates *do* have identity (you can overconstrain the
assembly by creating two identical mates, then delete one of them,
and it will still be constrained). A user can't possibly make
effective use of a feature-based modeller without thinking of
mates as objects or "separate things".
> Thus I am interested in relationship-oriented programming.
That's a fine thing to be interested in, but it doesn't (I believe)
present any necessary conflict with object-oriented programming.
Many people disagree with me on that point, though:
<http://c2.com/cgi/wiki?ObjectRelationalImpedanceMismatch>
--
David Hopwood <david.hopwood at industrial-designers.co.uk>
More information about the cap-talk
mailing list