Re: Aggregation vs composition

From: Matthias Hofmann (hofmann_at_anvil-soft.com)
Date: 05/04/04 

Date: Tue, 4 May 2004 15:48:51 +0200

> If two objects (A & C) share a reference to a third object (B), then A
> and C must cooperate in order to determine the disposition of B. Neither
> A nor C can be said to have "sole responsibility" for B. This is basic
> logic.

No, this is not logical at all. Sharing a reference does not mean sharing
responsibility for the destruction. Furthermore, only one object can be
responsible for the destruction of a part at all, as otherwise the object
could be destroyed twice (or more) - that is basic logic!

The object is destroyed by its owner, and this goes for C++ as well as Java.
In C++, the programmer is the one who decides who is the owner of a pointer
while in Java, this is done by an internal reference count: a reference in
Java is nothing but an object that destroys the object referenced by it when
the reference count is about to reach zero.

Maybe a composition relationship does not make sense for Java, but then
don't use it - the UML has not been designed just for Java programmers!

> If I am wrong then the following three diagrams are exactly equivalent:

No. If you are wrong, then the following three diagrams are NOT exactly
equivalent.

> 0..1
> [A]----------[B]-----[C]
>
> 0..1
> [A]<>--------[B]-----[C]
>
> 0..1
> [A]<#>-------[B]-----[C]
>
>
> Lastly, it cannot be denied that the ability to hide the objects one
> uses in its implementation is very important. To me, this means that a
> modeling notation that has no way of expressing such a relationship is
> flawed.

The idea of hiding the objects you use in your implementation is expressed
by not providing any operations to access these hidden parts.

> Where in the specification does it say that a part object in a composite
> can be shared?

The specification tells you so by not forbidding it. You are even allowed to
remove a part from a composite and have someone else take responsibility for
it.

Regards,

Matthias

Relevant Pages

  • Re: How java passes object references?
    ... Which everybody knows, it doesn't in Java. ... The reason I think this is a useful clarification is that when you got to the part about how passing by reference might work, it seems you went off track at least partly because you didn't understand the nature of the above. ... is a pointer pointing at the memory block. ... Assignments to local variables, or even to class members, do not allocate memory. ...
    (comp.lang.java.programmer)
  • Re: The Java no pointer big fat lie!
    ... > reference types, it wouldn't be a good comparison. ... and what you can't - and there is a big difference in Java to C and C++. ... You cannot change it in the language itself, ... Thus I would distinguish pointers from ...
    (comp.lang.java.programmer)
  • Re: call by reference
    ... We started learning Java about one month ago, and they just don't believe me when i try to explain that there is a confusion when passing reference types as an argumetn to a function. ... The actual parameter must be an L-value. ...
    (comp.lang.java.programmer)
  • Re: programming concepts > specific languages
    ... >actually changes the target of the reference passed to 'function2'. ... Java from a source that was not precise about terminology. ... if I have a class MyObject and write ... I thought primitive types in particular behave in the ...
    (comp.programming)
  • Re: no pointer in Java => my problem
    ... Does Java pass objects by reference or by value? ... f could also modify the StringBuffer by appending " World" for instance. ...
    (comp.lang.java.programmer)