Class relationships
Beyond inheritance and interface implementation, UML gives you five flavors of "this object knows about that one" - association, dependency, aggregation, composition, and realization - and mixing them up is the single most common way a class diagram lies to its reader. The difference between them is not academic hair-splitting: it's the answer to "if I delete this object, what else disappears with it," and getting it wrong means the next person to touch your code trusts a lifecycle guarantee that doesn't exist.
Each relationship gets its own page here because each one deserves more than a paragraph: precise UML notation (which end gets the diamond, solid line or dashed), multiplicity, whether the link runs one way or both, a full worked example, and - the part that actually matters in an interview - how to tell it apart from the neighbour you're about to confuse it with.
- Association - the base case: one object holds a reference to another, for as long as both are around. Start here; every other relationship on this page is association with an extra constraint bolted on.
- Aggregation - association's "has-a" cousin, where the whole holds the part but doesn't own its lifecycle.
- Composition - aggregation with the leash removed: the part cannot outlive the whole.
- Dependency - the loosest link of all: a temporary use, not a held reference.
- Realization - the odd one out, and the only one of the five that connects a class to an interface rather than to another class.
Before reading any of them, try naming a few of these from scratch - it's a useful gauge of what you already know versus what's about to get sharper:
A Car has an Engine, and the engine cannot exist without the car.