# Every class-typed variable is a reference, and the dot hides it

`Copy sameBook = onTheShelf;` reads like a copy. It duplicates the handle, so
`sameBook.markDamaged()` prints `Copy[978-0132350884#1, damaged]` when you print
`onTheShelf`. Same for a parameter: mutating through it reaches the caller's object, while
reassigning it reaches nothing.

Your next question is the C++ one. Two places now hold this book, the shelf's list and the
loan card in its pocket. Which of them owns it, and does the card get a `shared_ptr` or a raw
pointer? Java has no answer because it has no question. There is no `delete`, no destructor,
no dangling reference, and the cycle between a `Copy` and its `LoanCard` is collected like
anything else. Sharing costs you nothing.

Two things it does not buy you. `null` is the value every reference type accepts in silence:
`Copy copy = null;` compiles under `-Xlint:all` with zero warnings, and the failure waits for
the first `.`. And a reference in a long-lived collection keeps its object alive, so the leak
you can still write is the card left in the pocket after the book came back.

What replaces ownership is a question worth more marks: who is allowed to mutate this. Hand
out a defensive copy when the object is mutable, reachable from outside, and load-bearing for
one of your invariants. If any of the three is false, don't. Making the type immutable removes
the decision, which is what the corpus does with `Title` and `Loan`.
