[Tutor] The python implementation of the "class relationship".

Jerry Zhang jerry.scofield at gmail.com
Fri Nov 11 03:39:59 CET 2011


2011/11/11 Alan Gauld <alan.gauld at btinternet.com>

> On 10/11/11 09:23, Jerry Zhang wrote:
>
>> As you know, there are several kinds of relationships between classes in
>> the UML -- dependency, association, aggregation, composition.
>>
>
> There are several more besides, but lets not get carried away... :-)
>
>
>  Q1. Is there any article or code example on its implementation in python?
>>
>
> Probably if you try using google, but the principles are simple.
>
I tried and failed to find some code example. So i maybe i have to do such
very carefully by myself.

>
> Dependencies are both loose and implicit in Python.
> If an object uses another object in its implementation there is a
> dependency relationship, but the dependency is only on the operations
> exposed by the object not necessarily on the object, or even on
> its type.
>
> Association is likewise loose. If an attribute refers to another object
> then there is an association. If the referenced object is part of a
> collection then it is a 1-M association.
>
> Aggregation is a form of association and nothing more.
>
> Composition is a form of aggregation/association.
>
> Because of the way Python variables work object attributes can only ever
> be references to other objects, they objects are never tightly bound
> together.
>
Very fair comments. It deserve a big thanks.


>
> The relationships implied by UML are relationships of logical intent. In
> Python it's up to you to "enforce" the intent by the way you write your
> code. UML provides a wide variety of modeling concepts which the modeler
> can use depending on the concept he wishes to convey and also based on the
> implementation language. If designing for a language like C++ or Java it
> may make sense to specify precisely which relationship to use. In a freer
> language, like Python, you may just model everything as associations and/or
> aggregation. UML does not require anything more specific any more than it
> requires that you include deployment designs or state machines. They are
> tools in the toolbox, that's all. If you are sculpting in plasticine you
> probably don't need your power chisel, if you are using granite it might be
> useful. Pick the tool for the job.

To my understand, python's feature such as "name-reference-object" and
"garbage collection" system did some of work for you, it makes your life
easier, but you still need to add your explicit application in your code.

For example,
Composition implementation: you may need to do 5 job with C++, but only 2
job with python, the other 3 job is done by python implicitly.
association implementation: You need 3 job with C++, but 1 with python. it
seems python's object's lifecycle handling has reached this level, all you
should do is just "associating and de-association".

Here is exactly of my question, for composition,
 the best code may be you do 2 job explicitly, 3 job done by python
implicitly.
Code_Zero. 1 job(by you) + 4(by python) does NOT work.
Code_one. 2 job(by you) + 3(by python) works. That is the best one.
Code_two. 3 job( by you) + 2 (by python) works too,
Code_three. 4 job(by you) + 1(by python) works too.

Since i am not familiar with python yet, my code most likely would gets
into Code_two or Code_three(Code_Zero is also possible for new guys like
me), though they also work, they are bad code.
What i am looking for is the Code_one example, i thought many OOP
application designer may have met this issue, so a good Code_one reference
is the best choice to start this project.



>
>  Q2. More specific, in composition model, the container object may be
>> responsible for the handling of embedded objects' lifecycle. The common
>> way would be adding __del__ to the container class or something else?
>>
>
> That would be one way, and of course by having an __init__ method too.
> You might even go one step further and use a __new__ so that the
> relationship is already extant by the time the program hits __init__
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
>
>
> ______________________________**_________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/**mailman/listinfo/tutor<http://mail.python.org/mailman/listinfo/tutor>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20111111/7efb89e0/attachment-0001.html>


More information about the Tutor mailing list