Aggregation has the advantage of lower overhead,

Spotting the Difference

The general “thought test” to spot whether object A aggregates or composes object

B is to ask, “What happens if object A dies? Will object B still be alive?” If object

B outlives the death of object A, object A is said to aggregate object B. But if

object B dies when object A dies, then object A is said to compose object B.

In terms of practical development, knowing when to apply aggregation or composition

is important.

Aggregation has the advantage of lower overhead, because a single object will be

shared by many other objects. Certainly, aggregating your database connection

class is a good idea; composing it with every object that wants to make a query

may require you to have multiple connections to your database, which will quickly

halt your application when your site attracts high levels of traffic.

Composition has the advantage of making classes easier to work with from the

outside. The code that uses the class doesn't have to worry about passing it the

other objects it needs, which, in a complex application, can often become tricky

and result in a design “work around.” Composition also has the advantage that

you know exactly which class has access to the composed object. With aggregation,

another object sharing the aggregated object may do something to its state that

“breaks” the object as far as the other classes that use it are concerned.