Re: Aggregation vs composition

From: Ilja Preuß (preuss_at_disy.net)
Date: 04/27/04 

Date: Tue, 27 Apr 2004 17:42:04 +0200

Daniel T. wrote:
> "Ilja Preuß" <preuss@disy.net> wrote:
>
>> Daniel T. wrote:
>>
>>>>>>>>>>
>>>>>>>>>> |A|<#>----->|B|<--------|C|
>>>>>>>>>>
>>> Humm... If containment is being defined as "having life time
>>> responsibility for" then why would you use it when the whole doesn't
>>> have lifetime responsibility for its parts? If, in the diagram
>>> above,
>>> an A and C object both hold a reference to a B object, then the A
>>> object decidedly does *not* have lifetime control: A and C *share*
>>> that control.
>>
>> Control != Responsibility. A is responsible for controlling the
>> lifetime, C is not.
>
> However in the diagram above, C is just as responsible as A in
> managing
> the lifetime of the B objects they share. If two objects share a
> third,
> then they also share responsibility for the disposition of that third
> object.

In which way? Why can't I send messages to an object without being
responsible for its lifetime?

> Yes, A, if it knows all of the clients of a particular B object, could
> request that all those clients drop their reference, then drop its
> reference (thus "destroying" the object,) but being able to request
> that others stop using the object is not "responsibility for the
> disposition"
> of said object, if any one client refuses then the object being held
> doesn't get destroyed.
>
> Now I realize the above is only true in GC languages, in C++, A can
> explicitly destroy a B object at any moment, the other clients of
> that B object be damned. (Of course this applies to every client of
> that B object.)

Correct. In C++, it would be the responsibility of C to call the destructor
(or to give lifetime responsibility to someone else).

> First, if the composition relationship only matters in C++,
> then how is it language neutral?

It matters much less in a GC language. In such a language, it would be the
responsibility of C that B doesn't get GCed, that is, to maintain a
reference to it to keep it alive (not just to send messages to it).

> Second, A's ability to make such
> imperious demands on objects that it doesn't have responsibility for
> (namely other clients of B,) smacks of god class problems and IMO is
> irresponsible.

I don't follow you - what imperious demands are you talking about???

> If I'm
> wrong, look at your code and show me the difference between
> Composition and Aggregation.

In Java, you can't see the difference in the code. You also couldn't see the
difference between Aggregation and Association.

Isn't that one of the reasons why we use UML - because we can express things
that can't easily be expressed in code?

> Is it because (as someone has already said) that
> there
> is a line "delete child;" somewhere in the class? I dare say that that
> line exists *somewhere* or you have a leak. That would mean that *all*
> objects have a Containment relationship with *something*. The
> Containment relationship should be the most used relationship in UML
> if that were the case.

Unless we care less about the "completeness" of our diagrams and more about
depicting the *important* facts...

Take care, Ilja

Relevant Pages

  • Re: Aggregation vs composition
    ... > the lifetime of the B objects they share. ... > then they also share responsibility for the disposition of that third ... Nevertheless, holding a reference does not mean *controlling* lifetime, it ... > Yes, A, if it knows all of the clients of a particular B object, could ...
    (comp.object)
  • Re: Aggregation vs composition
    ... >> have lifetime responsibility for its parts? ... A is responsible for controlling the lifetime, ... Yes, A, if it knows all of the clients of a particular B object, could ... request that all those clients drop their reference, ...
    (comp.object)
  • Re: Articles or Turorials on Aggregation??
    ... > I think it is a matter of ownership, ... > to speak, owns the reference*, it is responsible for the lifetime of it. ... Responsibility for data? ... Suppose instead of exposing an actual string, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Aggregation vs composition
    ... >>lifetime of the B instances it holds. ... It shairs that responsibility. ... I would expect that any Python programmer looking at the above snippit ... I thought UML was supposed to be language ...
    (comp.object)
  • Re: Aggregation vs composition
    ... >lifetime of the B instances it holds. ... It shairs that responsibility. ... code the diagram above. ... A destroys B. The fact that C doesn't destroy B is irrelevant. ...
    (comp.object)