The python implementation of the "relationships between classes".

[Tim Wintle]

On Thu, 2011-11-10 at 22:25 +0800, Jerry Zhang wrote:
> 
> 
> 2011/11/10 Chris Angelico <rosuav at gmail.com>
>         On Fri, Nov 11, 2011 at 12:58 AM, Jerry Zhang
>         <jerry.scofield at gmail.com> wrote:
>         > Cls_a:
>         >     def __init__(self):
>         >         self.at1 = 1
>         > Cls_b:
>         >     def __init__(self):
>         >         self.com1 = Cls_a()
>         >     def __del__(self):
>         >         del self.com1
>         > Is it a right implementation for composition?
>         
>         
>         Yes, except that you don't need to explicitly del it. Python
>         (at
>         least, CPython) is reference-counted; your Cls_b object owns a
>         reference to the Cls_a object, so (assuming nothing else has a
>         reference) that Cls_a will be happily cleaned up when the
>         Cls_b is.
>         
>         Python doesn't really talk about "composition" etc. It's much
>         simpler:
>         everything's an object, and you have references to that
>         object. A
>         named variable is a reference to some object. A member on an
>         object
>         is, too. Whenever an object is expired, all objects that it
>         references
>         lose one reference, and if that was the sole reference, those
>         objects
>         get expired too. It's a change of thinking, perhaps, but not a
>         difficult one in my opinion; and it's so easy to work with
>         when you
>         grok it.
> 
> 
> Unfortunately there is a difference between composition and
> aggregation in my real word, and my application really care this since
> it is trying to simulate this real world model, so my system should
> track this difference accurately, otherwise the system may not work
> well. 

You might want to look into weak references:
http://docs.python.org/library/weakref.html

Although I agree with Chris that it sounds like your code might be
easier with a change of perspective (I've not done much UML, but the way
you're describing things sounds like a java-ish way of looking at it to
me)

> For example, 
> a. the Cls_arm and Cls_body may be composition, but not aggregation.
> My app must ensure that " one arm instance only live with one body
> instance, if the body instance die, the arm instance must die.
>  b. the Cls_auto and the Cls_tyre may be aggregation. "One tyre still
> can live even the auto is dead."

That behaviour isn't really hard-coded as part of the language in
python, as it's not required for memory management in the same way it
would be in C++ or langauges without GCs.

As long as no objects other than body objects hold a reference to arm
objects then the arm object will be deleted.

For The tyre object to be deleted when the auto object is deleted, there
would have to be no references left to the tyre object. If there aren't
any references then you can't know if it exists or not anyway, so the
distinction isn't useful.

> Meanwhile, I have a ZODB running, which stores all the living
> objects. 

The ZODB is append only and stores all objects. Deleting references to
an object (which would causes deletion of standard python objects) won't
delete it from the zodb, it'll just delete the references.