This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Aggregation vs. Composition

Posted by Bill Venners on 04 Nov 1998, 10:47 PM

> Hi,

> What about aggregation ? Is it not the other side of composition ? I view aggregartion as holding a reference to an object which exist outside the current object, otherwise same as composition.

> Couple of good thigs happen here:

> 1. Performance hit might be reduced as the object is already created

> 2. More importantly, it can do distributed processing ! The aggregated object need not me in the same namespace of the aggregator !(Pardon the nouns). Try to do this with inheritence !

> I think, when we talk about composition, we should consider aggregation also especially in this age of distributed computing.

I do have a few things on my mind about unloading, which your
question graciously gives me the opportunity to do.

I see composition and aggregation as opposite ends of
a conceptual spectrum. At the composition end, constructors
and instance methods create back-end objects and stick
references to the back-end objects into its own instance
variables. At the aggregation end, container objects are
given references of objects to hold onto and then give
back in some fashion. In the middle are objects which are
passed references to other objects and which store those
references in their instance variables, but which are not
necessarily "container objects" and may or may not
provide a way for the outside world to get at those
object references.

My feeling is that it is best to stay at one end of the
spectrum or the other. In other words, its OK to accept
and give back object references (to use Aggregation) if
your purpose is to serve as a container for objects.
Otherwise, try to use Composition by one of these methods
(in order of preference):

1. Creating the back-end objects in the front-end objects
   constructors or methods
   
2. Accept references to the back-end objects in the
   front-end constructors, under the assumption that only your
   object will ever use those back-end objects.
   
3. Accept references to the back-end objects in the
   front-end constructors or methods, under the assumption that
   only your object will ever use those back-end objects.
   

In all three of the above cases, your front-end object would
never return a reference to any of the back-end objects. In
my mind, Composition means that the front-end object is the
only object that will ever use the back-end objects.

If an object allows other objects to get at the references
of its back-end objects, or if the code that creates the
back-end objects in the first place to pass to the front-end
class's constructor or methods also uses the back-end objects
in some other way, you've got Aggregation.

So I see the difference between composition and aggregation
as a conceptual one primarily. To me, composition means
a front-end object is the "sole owner" of a back-end object;
aggregation means a front-end objects host back-end objects
as "guests" that can be shared among many front-end objects
sequentially or concurrently or both.

One distinction that may be in order with regards to composition
vs. aggregation is in how the clone() method is implemented.
Someone e-mailed me or posted to this forum that Vector does
a shallow copy, in other words, it doesn't clone the objects
it contains. I am still not sure if this is true, because the
documentation doesn't say shallow copy anywhere, and I haven't
had a chance to try it. I also want to try it with all the new
container classes in JDK 1.2. But, if it is true that container
classes clone() methods do shallow copies, then that would
be one difference between composition and aggregation. In
composition, a front-end object's clone() method should clone()
any mutable back-end objects. In aggregation, by contrast,
a front-end object's clone() method should not clone() the
back-end objects.

Oh and by the way, the same object can have some back-end objects
that are composition and others that are aggregation.

That's about all I have in my head right now on this topic. I
am not sure where the Visitor pattern fits into the above
ideas, and I plan to look at that. I welcome feedback.

bv