Java Reference
In-Depth Information
A
DVANCED
T
OPIC
12.3: Aggregation and Association
Some designers find the aggregation or has-a terminology unsatisfactory. For
example, consider customers of a bank. Does the bank Ȓhaveȓ customers? Do the
customers Ȓhaveȓ bank accounts, or does the bank Ȓhaveȓ them? Which of these
Ȓhasȓ relationships should be modeled by aggregation? This line of thinking can
lead us to premature implementation decisions.
Early in the design phase, it makes sense to use a more general relationship
between classes called association. A class is associated with another if you can
navigate from objects of one class to objects of the other class. For example, given
a
Bank
object, you can navigate to
Customer
objects, perhaps by accessing an
instance field, or by making a database lookup.
The UML notation for an association relationship is a solid line, with optional
arrows that show in which directions you can navigate the relationship. You can
also add words to the line ends to further explain the nature of the relationship. An
Association Relationship shows that you can navigate from
Bank
objects to
Customer
objects, but you cannot navigate the other way around. That is, in this
particular design, the
Customer
class has no mechanism to determine in which
banks it keeps its money.
An Association Relationship
543
544
Frankly, the differences between aggregation and association are confusing, even
to experienced designers. If you find the distinction helpful, by all means use the
relationship that you find most appropriate. But don't spend time pondering subtle
differences between these concepts. From the practical point of view of a Java
programmer, it is useful to know when objects of one class manage objects of
another class. The aggregation or has-a relationship accurately describes this
phenomenon.
