Re: Aggregation vs composition

From: Daniel T. (postmaster_at_eathlink.net)
Date: 04/28/04 

Date: Wed, 28 Apr 2004 12:26:48 GMT

"Matthias Hofmann" <hofmann@anvil-soft.com> wrote:
> Daniel T. <postmaster@eathlink.net> schrieb:
> > "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. I'm not sure why I'm having such a hard time getting this across.
>
> Obviously your concern is the problem of dangling references and wild
> pointers, which is indeed something a programmer has to be aware of.
> Nevertheless, holding a reference does not mean *controlling* lifetime, it
> rather means *depending on* lifetime. In your A-B-C example, the C object is
> NOT responsible for the disposition of the B object.

This is the very statement which I am in disagreement with. If a
particular B object is being held by both an A object and a C object,
then they share the lifetime responsibility, they must cooperate with
eachother in order for the B object to be destroyed. Let's diagram this
another way, on the left we have "the set of all objects holding a
reference to B's" (I'll call it X):

[X]<#>--->[B]

No obviously, both A and C belong to this set...

> > 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.
>
> If any of the clients refuses, then its his own fault, as he will end up
> with a dead reference. A is not asking for permission to destroy B, it
> merely informs C that B is about to go up in smoke, no matter wether C wants
> or not.

This is only true in C++. If Composition only applies if the system is
implemented in C++, I would agree with you. However, UML is supposed to
be language neutral.

> > 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.) First, if the composition relationship only matters in C++,
> > then how is it language neutral? 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.
>
> This problem is not created by the UML. The UML only makes implementers
> aware of such things, and that's the goog thing about the UML being able to
> show such situations.
>
> >
> > Maybe we will just have to agree to disagree, but I ask this: If I'm
> > wrong, look at your code and show me the difference between Composition
> > and Aggregation.
>
> Take a look at my other post.
>
> > 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
>
> No, you only need to delete objects that are allocated dynamically. Use a
> regular data member and you have composition also:
>
> class Part {};
>
> class Whole
> {
> Part part;
> };

And woe be the code that allows a Whole to go out of scope, if it's part
is shared with something else. What class is in charge of insuring that?
That is where the true lifetime responsibility lies... If you say that
no class has this responsibility? Then I must counter, "then the entire
system has that responsibility" and that is a very sorry state to be in.

> > Containment relationship should be the most used relationship in UML if
> > that were the case. Is it because some object happens to be the last one
> > to hold a reference to some other, thus when that reference is dropped
> > the object is gone? Again, this could be said of every object in the
> > system...
>
> Reference counting not always present. Objects do not always keep track of
> how many other objects hold references to them. Often, it is a matter of
> timing - you usually know when an object goes out of scope, as the rules on
> that are very clear (at least in C++). You simply don't use an object after
> it has been destroyed.

When objects are shared, reference counting is *always* present, even if
only in the programmers head. At the very least, the programmer must
know that at every point in the code where an object goes out of scope,
there is only one other object holding a reference to it. He can't
guess, wonder or hope, he must know.

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
    ... Is this not Composition, ... responsibility for them, like in your example. ... Just because there's a method that returns a reference doesn't imply ... that this reference is used to destroy the referenced object. ...
    (comp.object)
  • Re: cruiseshopping web site
    ... "Countryside Travel ... their total declaimer information for reference, ... You continue to take great pains to deny any responsibility for your ... Your disclaimer actually says that even if you knowingly give ...
    (rec.travel.cruises)
  • Re: Aggregation vs composition
    ... >This could be easily achieved when Unit keeps a reference count, ... >has sole responsibility for its own destruction, ... >it only means that no one else except for the whole is allowed to destroy ...
    (comp.object)
  • Re: Aggregation vs composition
    ... >The lifetime issue is a side effect. ... If only one object has a reference ... Composition does not imply that other objects cannot hold references ... responsibility for the component at any given time. ...
    (comp.object)