Re: Aggregation vs composition

From: Michael Rauscher (michlmann_at_gmx.de)
Date: 06/05/04 

Date: Sat, 05 Jun 2004 17:55:52 +0200

Matthias Hofmann schrieb:

> Michael Rauscher <michlmann@gmx.de> schrieb in im Newsbeitrag:
> c9se8e$i3l$03$2@news.t-online.com...
>
>>Daniel T. schrieb:
>>
>>
>>>>[Organization]<>----[Unit]<----[Person]
>>>>
>>>>Who's responsible for destroying the Unit now?
>>>
>>>
>>>The same one that was always responsible. The last one to hold a
>>>reference to it.
>>
>>IOW: If one destroys the Organization, it's Person that is responsible
>>and if one destroys the Person, it's Organization that is responsible?
>
>
> This could be easily achieved when Unit keeps a reference count, e.g. using
> the smart pointer I mentioned earlier (in C++) and I guess Java does a
> similar thing under the hood.

That's a technical issue where I'm not interested in while modeling. The
point isn't if a specific language offers constructs that makes it easy
to realize the model's semantics. So, it might be, that (at
implementation level) you aren't able to destroy an object like in Java.
But that doesn't change the semantics.

My question doesn't refer to what happens to the implementation level
but to the semantics of the model. If one answers my question with yes,
this means, that if the owner of the organization destroys it, the
employees are responsible to what happens with the units. Do you think so?

>
> I read an interesting statement about ownership that I agree with: if an
> object employs reference counting, than it owns itself!
>
> You could see this as a whole/part relationship of Unit with itself, it is a
> part that acts like its own whole at the same time. This implies that Unit
> has sole responsibility for its own destruction, but I already see trouble
> brewing: if it has sole responsibility, is it allowed to destroy itself
> before its reference count reaches zero?
>
> The way I understand the phrase about "sole responsibility for destruction",
> it only means that no one else except for the whole is allowed to destroy
> the part. I think it does not mean that the part may be destroyed while
> there are good reasons to assume that someone might still need it.
>
> By the way: if there is no 1:1 mapping between a model class and an
> implementation class, what do I need the UML diagram for? It would be like

If there would be a 1:1 mapping between a model class and an
implementation class you wouldn't need a model. Due to the complexity of
real world problems you have first to model it. It makes life easier
having steps between the real world problem and the implementation. As
you agree that information might be lost between the steps (model=>code)
I assumed you agree that there isn't a 1:1 mapping.

Having a 1:1 mapping would mean that given only the code one would be
able to create a unique model. But that isn't the case. E.g. association
and aggregation are implemented often in the same way. So by just
looking at the code you can not always say if the relation between A and
B is an aggregation or not.

Now, one could say, that if it's implemented in the same way, one
doesn't need to differentiate between an aggregation and an association.
But I don't think, that this would be the case. First, this assumption
relies on specific languages (another language might distinguish between
aggregation and association). Second, there's some semantics behind an
aggregation, that an association doesn't imply. These semantics might
become important later, when changing the model/implementation.

> having a blue print for a house that has a totally different structure in
> reality...

One should alway be as close to the model as possible. But if the
language doesn't directly support the realization of the semantics then
I think it would be a bad way to say: change the model. Remember, that
one could implement the model even with a non-OOPL.

Bye
Michael

Relevant Pages

  • Re: Aggregation vs composition
    ... responsibility is shared because the object is shared. ... Is this not Composition, simply because Car is ... may destroy the part. ... >> other language that I'm aware of. ...
    (comp.object)
  • Re: Aggregation vs composition
    ... But if you destroy the car without having the engine removed, ... >> aggregation involves construction, I just thought that the aggregation ... Composition is easy to explain, but the concept of aggregation in the UML ... But what if I store pointers to objects in a std::vector? ...
    (comp.object)
  • Re: Aggregation vs composition
    ... and as composition is transitive, the engine is part of Car, too. ... remove them) can be taken in responsibility for destroying them. ... >>This applies to every language where the programmer has full control on ... In a language, where one can destroy objects explicitly, it's not a big ...
    (comp.object)
  • Re: False rape accusation & misplaced chivalry
    ... by a lying tart. ... She didn't destroy the life of ... He bears full responsibility for ... Just because radical feminists blame men for all the ridiculous things ...
    (soc.men)
  • Re: Aggregation vs composition
    ... But if you destroy the car without having the engine removed, ... > But that is another example for composition, not aggregation, isn't it? ...
    (comp.object)