Generalization, Aggregation, Association, and Cardinality

This chapter covers various types of relationships between objects in system design.
We have already covered inheritance and composition of Java classes.
Now we take a look at these relationships from the system design prospective.
That is, how do we express relationships between objects early on, even before programming code is written?

Inheritance is an "is-a" relationship. also known as generalization.
For example, Employee is a Person.
On true contrary, composition relationship represents interaction between objects.

Composition aids modularity.
That is, composition allows to build large and complex software from small components.
Breaking complexity into smaller pieces helps to
- increase stability
- reduce number of baggage
- simplify testing of individual classes and components.

It is now a good time to examine various types of composition relationships between objects in greater detail.
The two major type of composition are association and aggregation.
All forms of composition are expressed as has-a relationship.
Aggregation presumes equal lifetimes of both outer object and its inner parts.
Association, on the other hand, makes inner parts visible from the outside, thus making association similar to navigable path from one object to another.

Aggregation is a complex object constructed from other objects.
Association is a combination of independent objects which interact with one another.
Use your judgment when to use one or the other - design is not an exact science.
Hint: aggregation usually indicates strong relationship.

Associations support the notion of cardinality.
In math cardinality specifies a number of elements in a set.
Cardinality specifies:
- the number of objects that participate in an association
- whether the participation is optional or mandatory.
Cardinality 1-to-1 usually indicates aggregation.