Association, Aggregation and Composition in Java - Quiz

Both describe a "part-whole" link, but they differ in coupling strength and in the lifecycle of the part. With aggregation the part is created by external code and passed to the whole (through a constructor or a setter), it may belong to several wholes and it survives when the whole is gone: new PC(keyboard), a department and its employees. With composition the whole creates the part inside its own constructor, the part belongs only to that owner and dies with it: this.keyboard = new Keyboard(), a house and its rooms. In UML aggregation is a hollow (white) diamond at the whole, composition is a filled (black) one.

IS-A ("is a") is based on class inheritance or interface implementation: class Lorry extends Car means Lorry IS-A Car, and class Transport implements Moveable means Transport IS-A Moveable. You can check IS-A at runtime with the instanceof operator. HAS-A ("has a") is based on usage: one class keeps a reference to an object of another class in a field - class Car { Engine engine; } means Car HAS-A Engine. Association, aggregation and composition are all refinements of HAS-A.

Association is the umbrella term for a relationship in which objects of two classes may refer to each other: class Person { private Car car; }. Aggregation and composition are special cases of it. By direction an association is unidirectional (only one class knows about the other) or bidirectional (both keep references). By multiplicity it is one-to-one (a person and their car), one-to-many (a shop and its categories) or many-to-many (students and courses); the "many" side is expressed with a collection or an array. A bidirectional link must be updated on both sides in a single method, otherwise the data goes out of sync and toString() or equals() may fall into infinite recursion.

The rule comes from Design Patterns by the Gang of Four and is repeated by Joshua Bloch in Effective Java. Overused inheritance makes code fragile (a change in the base class breaks its subclasses), breaks encapsulation (a subclass depends on the parent's implementation details), produces a rigid hierarchy fixed at compile time, and runs into Java's ban on multiple inheritance. Composition is more flexible: instead of class Driver extends Employee give the employee a private Role role field - the role can be swapped at any moment through a setter. Inheritance is justified only when the subclass is a full substitute for its parent (the Liskov substitution principle) and you control both classes.

A dependency is the weakest link: the class does not store the object in a field, it receives it as a method parameter, creates it locally or returns it, so the link exists only for the duration of the call. Example: void print(Printer printer) in ReportService, which has no Printer field. Ordered by growing coupling strength the relationships line up like this: dependency, association, aggregation, composition, inheritance. The stronger the link, the harder it is to change the classes independently, which is why loose coupling is a design goal.