Question
Which practice avoids a common mistake with Immutable Class Design?
- Do not leak internal mutable fields through constructors or getters if the type claims to be immutable.
- Ignore the Immutable Class Design issue and rely on team discipline instead of APIs or contracts.
- Silence the Immutable Class Design problem by using raw types, broad catches, or shared mutable state.
- Prefer the version of Immutable Class Design that makes behavior less predictable as long as the code compiles.
Hint
Look for the option that protects correctness instead of hiding the problem.
Answer and rationale
Correct answer: A. Do not leak internal mutable fields through constructors or getters if the type claims to be immutable.
Do not leak internal mutable fields through constructors or getters if the type claims to be immutable. This is a common failure mode in real Java code and a frequent interview follow-up.
Track: Java