The python implementation of the "relationships between classes".

[Jerry Zhang]

2011/11/11 Benjamin Kaplan <benjamin.kaplan at case.edu>

> On Thu, Nov 10, 2011 at 1:06 PM, Jerry Zhang <jerry.scofield at gmail.com>
> wrote:
> >
> >
> > I just did an example code to describe what i am looking for.
> >
> /*------------------------------------------------------------------------------------------------*/
> > # ...
> >
> > class Head:
> >     def __init__(self):
> >         self.size = 5
> >
> > class Hat:
> >     def __init__(self):
> >         self.color = red
> >     def took_on(self, body):
> >         self.body = body
> >     def took_off(self, body):
> >         del self.body
> >
> > class Body:
> >     def __init__(self):
> >         self.head = Head()
> >     def take_on_hat(self, hat):
> >         self.hat = hat
> >         hat.take_on(self)
> >     def take_off_hat(self):
> >         hat.take_off(self)
> >         del self.hat
> >     def go_to_heaven(self):
> >         take_off_hat(self)
> >         del self.head
> >
> /*----------------------------------------------------------------------------------------------------------*/
> >
> > In this example, Head and body are COMPOSITION, which means
> > a. A head only live with one body, it can not live with other body. It
> can
> > not even live without body
> > b. If the body go to die, the head also go to die.
> >
> > Body and Hat are aggregation, which means
> > a. A hat live isolate with body, its life circle is isolate
> > b. A hat only live with one body at a specific time, it can not live with
> > two body(association would be more than one)
> >
> > So when the body die, the clean dead should include take_off Hat and del
> > Head, otherwise, the code definition is not prciselly describing the
> > relationship, which may cause a mess system, for example, a body has
> dead,
> > but one hat is still associated with a unreferenced body.
> > A point on this issue, maybe python is smart that the take_off_hat(self)
> is
> > not needed in go_to_heaven() method(i am not sure yet), but the del
> > self.head is sure needed, otherwise, we will have a no_body_head in our
> > ZODB, that is extremely horrible, right?
> >
> > All of these points one, the four kinds of class relationship in UML
> > precisely describe the real word, if the implementation is not precisely,
> > you will have unexpected results.
> > Of course, python may be smart to achieve such goal with less effort,
> that
> > is why i am asking for a code example for all of the four relationships.
>
> You're still misunderstanding Python's object model. del does NOT
> delete an object. It deletes a name. The only way for an object to be
> deleted is for it to be inaccessible (there are no references to it,
> or there are no reachable references to it).
> >>> foo = object()
> >>> bar = foo
> >>> foo
> <object object at 0x01CE14C0>
> >>> bar
> <object object at 0x01CE14C0>
> >>> del foo
> >>> bar
> <object object at 0x01CE14C0>
> >>> foo
>
> Traceback (most recent call last):
>  File "<pyshell#7>", line 1, in <module>
>    foo
> NameError: name 'foo' is not defined
>
>
> There is no way to force the go_to_heaven method to delete the head
> unless you can make sure that all other references to the head are
> weak references. If you need strictly-enforced relationships, Python
> is probably not the right language for the job- you'll be better off
> with C++ or Java.
>

Thanks for your reply, but i know your point on this before post this
issue. "doing the the job of python's garbage collecting" system is not i
want.
What i am trying to do is a python implementation of the real "composition
implementation".

> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20111111/6ee9a7e8/attachment.html>