When you compose a mutable object inside a class, what goes wrong without defensive copying, and how do you fix it?

## Why composition needs defensive copying **Composition** means a class *exclusively owns* a part — no outside code should be able to reach in and change it. Java makes that ownership easy to violate because of two facts: 1. **Java is pass-by-value, but for objects the *value* is the reference.** When you pass an object to a constructor, the method gets a **copy of the pointer**, not a copy of the object. Both the caller and your field now point at the **same** object on the heap. 2. **Many objects are mutable** — `Date`, `ArrayList`, `int[]`, most domain objects — meaning their internal state can be changed after construction. Put those together and you get a **reference leak**. ### The inbound leak ```java final class Period { private final Date start; Period(Date start) { this.start = start; } // stores the caller's object Date start() { return start; } } Date d = new Date(); Period p = new Period(d); d.setTime(0); // caller still holds d → just mutated Period's internal state! ``` Even though `start` is `final`, `final` only stops the **reference** from being reassigned — it does nothing to stop the **referenced object** from being mutated. The caller kept `d`, so they can rewrite the period after the fact, defeating encapsulation and any invariant (e.g. start ≤ end). **Fix — copy on the way in:** ```java Period(Date start) { this.start = new Date(start.getTime()); } ``` Now the field points at a private copy the caller cannot reach. ### The outbound leak ```java Date start() { return start; } // returns the live internal reference ... p.start().setTime(0); // caller mutates the internal Date through the getter ``` **Fix — copy on the way out:** ```java Date start() { return new Date(start.getTime()); } ``` ### Copy *before* you validate (the TOCTOU trap) If you validate the argument and *then* copy, a malicious caller running on another thread can mutate the object in the gap between your check and your copy — a **time-of-check-to-time-of-use (TOCTOU)** attack. Always **copy first, then validate the copy**: ```java Period(Date start, Date end) { this.start = new Date(start.getTime()); // copy first this.end = new Date(end.getTime()); if (this.start.after(this.end)) // validate the copies throw new IllegalArgumentException("start after end"); } ``` Also: don't use `clone()` to copy a parameter whose type is non-final, because the caller could pass a malicious subclass whose `clone()` does something hostile. ### Collections: copy, don't just wrap For a `List` field, `Collections.unmodifiableList(input)` returns a **view** over the caller's live list — the caller still holds the original and can add to it, and the change shows through your 'unmodifiable' view. To truly own it, **copy**: `new ArrayList<>(input)` (mutable internal) or `List.copyOf(input)` (immutable snapshot). For nested mutable elements you need a **deep copy** of each element too, not just a new outer list. ### The shortcut: immutable parts If the part type is **immutable** — `String`, `Integer`, `LocalDate`, an immutable record, a `List.copyOf(...)` of immutables — there is **nothing to copy** because no one can mutate it. This is a major reason 'favor immutability' pairs with 'favor composition': immutable parts make exclusive ownership free. ### Aggregation is the deliberate exception Defensive copying is for **composition** (exclusive ownership). In **aggregation** the part is *meant* to be shared and live independently, so you intentionally store the passed-in reference *without* copying — sharing is the feature. Knowing which relationship you're modeling tells you whether to copy. ### Summary checklist - Mutable composed part? Copy in (constructor/setter) **and** out (getter). - Copy **before** validating. - Use a real copy (`new ArrayList<>`, `new Date(...)`), not an unmodifiable *view*. - Deep-copy nested mutable graphs. - Immutable part ⇒ no copy needed. - Aggregation ⇒ share on purpose, don't copy.