Association, Aggregation & Composition

## The three strengths of a link All three are "object A holds a reference to object B"; they differ in the claim the model makes about B's lifetime and exclusivity. - **Association** - A knows about B so it can call it. No lifetime claim, no ownership. A trip knows its car. - **Aggregation (shared)** - B is treated as a part of A for the purposes of A's behaviour, but B exists independently, may be part of several wholes, and outlives any one of them. A fleet aggregates cars. - **Composition (UML: composite aggregation)** - A owns B exclusively. B belongs to at most one whole at a time and does not outlive it. A car is composed of an engine; delete the car and the engine goes with it. ## What the notation records On a UML class diagram a plain line is an association. An arrowhead marks **navigability** - which end can reach the other, and it is per end, so a link can be one-way. Numbers at each end are **multiplicity** (`1`, `0..1`, `*`, `1..*`), and constraints such as `{ordered}` or `{unique}` at the many end decide which collection type the code should use. A hollow diamond at the whole means shared aggregation; a filled diamond means composite aggregation. The diamond always sits at the *whole*, never at the part. ## Where the claim becomes executable The interesting question is not the notation but who enforces it. **C++** encodes it in the declaration. `Engine engine;` is a subobject: its destructor runs as part of the enclosing destructor, its storage is inside the whole, and it cannot be shared. `std::unique_ptr<Engine>` is the same claim with heap storage and a movable owner. `std::shared_ptr<Engine>` or a raw pointer is aggregation or association. The compiler therefore distinguishes all three, and the price is that you now own copy, move and slicing decisions for the whole. **Rust** goes further because ownership is checked. A `struct Car { engine: Engine }` moves the engine in; when the car is dropped, the engine is dropped, and the borrow checker refuses to let a reference to the engine outlive the car. Sharing requires `Rc`/`Arc` explicitly, and a non-owning link is `&'a Engine` with a lifetime that must be provably shorter than the owner's. The whole model is visible in the type. The price is real: a part that needs to point back at its whole cannot be expressed with plain ownership at all. **Swift** uses automatic reference counting. Strong references keep an object alive and there is no tracing collector to clean up cycles, so a wrongly modelled relationship is not a documentation defect but a permanent leak. `weak` and `unowned` are how you say "association, not ownership", and the compiler makes you choose. **Java, C#, Kotlin, Python, Go, JavaScript** all use tracing (or, in CPython's case, refcounting plus a cycle collector) and none of them treats a field as an ownership statement. `private Engine engine;`, `private List<Car> cars;` and `private Car car;` are the same construct; the object dies when nothing can reach it, regardless of your diagram. So in these languages the diamond is a comment - with one important exception. ## The exception: non-memory resources Garbage collectors manage memory, not file handles, sockets, connections or native buffers. For those, composition has teeth even in Java or C#: the owner of a resource must release it (`AutoCloseable`/try-with-resources in Java, `IDisposable` and cascading `Dispose` in C#, `defer x.Close()` behind `io.Closer` in Go, `__exit__` in a Python context manager), and a class that merely *aggregates* a resource it did not create must **not** close it. A large share of "stream closed" and "connection already returned to the pool" bugs are exactly an aggregation modelled and coded as a composition. So even where the compiler is indifferent, deciding the diamond decides who calls close. ## How to use this in practice First ask whether the part can be handed to a second whole, and whether it is meaningful once the whole is gone. Two noes mean composition. Then ask what your language will do about it: in C++ or Rust, express it in the type and get it checked; in Swift, express it in the strength of the reference; in a GC language, express it wherever a tool can execute it - the disposal chain, and (see the persistence question in this topic) the cascade rules of your ORM. Anywhere else it is prose, and prose does not stop a caller from keeping the part alive.