[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