Why can a getter or setter that exposes a mutable internal object break information hiding, and how do you fix it?

## The trap: private isn't the whole story Beginners learn "make fields private and add a getter" and assume the state is now protected. But in Java, a getter that **returns the field** returns a **reference** to the same object the class holds. If that object is **mutable** (can be changed in place), the caller now has a handle to your internal state and can modify it without ever calling your class. The `private` keyword stopped them from *reassigning* the field, but not from *mutating the object the field points to*. This is called a **reference leak** (or letting state "escape"). ### Key terms - **Mutable object:** an object whose contents can change after creation, e.g. `ArrayList` (add/remove), a primitive array, or the legacy `java.util.Date`. - **Immutable object:** one whose state never changes after construction, e.g. `String`, `Integer`, `java.time.LocalDate`, or a list made with `List.copyOf`. - **Reference:** in Java, object variables hold a reference (a pointer) to the object, not the object itself. Returning the field copies the reference, not the object. - **Defensive copy:** making a fresh, independent copy of a mutable object on the way in (in a constructor/setter) and/or on the way out (in a getter), so the internal and external copies can't affect each other. ## A broken example ```java public class Schedule { private List<String> slots = new ArrayList<>(); public List<String> getSlots() { return slots; } // leaks the real list public void setSlots(List<String> slots) { this.slots = slots; } // stores caller's list } ``` Problems: ```java Schedule s = new Schedule(); s.getSlots().add("hack"); // mutated internal state, no validation ran List<String> external = new ArrayList<>(); s.setSlots(external); external.add("sneaky"); // external list IS the internal one now ``` Both the getter and the setter share the *same list object* with the outside world. Any invariant `Schedule` wanted to enforce (max slots, no nulls, etc.) is bypassed. ## The fixes ### 1. Defensive copy on input (constructor/setter) ```java public void setSlots(List<String> slots) { this.slots = new ArrayList<>(slots); // copy: caller's later edits don't reach us } ``` Now the field points to *our* list, independent of the caller's. ### 2. Defensive copy or unmodifiable view on output (getter) ```java public List<String> getSlots() { return List.copyOf(slots); // independent immutable snapshot // or: return Collections.unmodifiableList(slots); // live read-only view } ``` `List.copyOf` returns an immutable copy — mutations throw and don't touch the field. `Collections.unmodifiableList` returns a *view*: read-only to the caller, but it still reflects later internal changes (and the caller can't mutate it). ### 3. Best: use immutable types so there's nothing to leak If the field is already immutable (`List.copyOf(...)` stored once, `LocalDate` instead of `Date`, a record of immutable components), you can return it directly with zero copying because no one can mutate it. This is why modern Java favors `java.time`, `List.of`/`Map.of`, records, and final immutable fields — they make this whole class of bug impossible. ## Arrays are the sharpest edge Arrays are always mutable and have no read-only view, so a `getData()` returning the array, or storing the passed-in array, both leak. You must `clone()` or `Arrays.copyOf` on the way in and out. ## Why this is a hiding question, not just a bug Information hiding's whole point is that the class *controls* its state. A leaked mutable reference is an uncontrolled write path into private state — it defeats validation, breaks invariants, and can cause subtle aliasing bugs and thread-safety problems (two parties mutating the same object). So "private field + naive getter/setter" only *looks* encapsulated. Real hiding requires controlling not just access to the field but access to the *object the field points to*. ## Trade-off Defensive copying costs allocation and CPU on every call. For hot paths or large structures you may instead document immutability expectations, return an unmodifiable view (cheaper than a copy), or design with immutable types from the start so copying is unnecessary.