Re: Aggregation vs composition
From: Daniel T. (postmaster_at_eathlink.net)
Date: 04/27/04
- Next message: Daniel T.: "Re: Observer: Should messages carry data?"
- Previous message: Jason: "Re: Lazy Load and Inheritance Mappers (Fowler Patterns)"
- In reply to: Ilja Preuß: "Re: Aggregation vs composition"
- Next in thread: Ilja Preuß: "Re: Aggregation vs composition"
- Reply: Ilja Preuß: "Re: Aggregation vs composition"
- Reply: Matthias Hofmann: "Re: Aggregation vs composition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 27 Apr 2004 12:22:24 GMT
"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.
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.) 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.
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. 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. 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...
- Next message: Daniel T.: "Re: Observer: Should messages carry data?"
- Previous message: Jason: "Re: Lazy Load and Inheritance Mappers (Fowler Patterns)"
- In reply to: Ilja Preuß: "Re: Aggregation vs composition"
- Next in thread: Ilja Preuß: "Re: Aggregation vs composition"
- Reply: Ilja Preuß: "Re: Aggregation vs composition"
- Reply: Matthias Hofmann: "Re: Aggregation vs composition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
