| Claim | Verdict |
|---|
| Encapsulation means adding getters and setters | No. The access control is the point. |
| Private fields guarantee privacy | No. A getter can leak a reference. |
| Getters must return a stored field | False. They may compute a value. |
| A setter is always needed | False. Omitting it makes the property read-only. |
| Returning an unmodifiable list is enough | Yes. That is the correct pattern. |
| Public fields are always wrong | No. Constants and short-lived holders are fine. |
Encapsulation requires final | No. It helps, but hiding is what matters. |
| Records break encapsulation | False. They hide fields and expose accessors. |
Frequently Asked Questions
What is the real benefit of encapsulation?
It gives the class control over its own invariants. Because callers cannot reach the fields, every rule about valid state can be written once and enforced in one place, so an object cannot exist in a state the class considers invalid. It also buys freedom to change the representation later without breaking callers.
Are getters and setters required for encapsulation?
No. They are one possible way to expose behaviour, not the definition itself. The defining feature is that callers cannot touch internal state directly. A computed getter needs no field at all, and a read-only property needs a getter with no setter.
How do I make a class read-only?
Make every field private and final, validate in the constructor, provide getters, and write no setters. With no setter and no reassignment path, the object cannot change after construction. A record gives you exactly this shape with far less code.
Why is returning a private List unsafe?
Because the reference is the object, not a copy of it. A caller that receives your private list can add or remove through it, so private state changes with no setter involved and no compile-time signal. Return an unmodifiable view or a defensive copy instead.
Should a getter return a copy or the live collection?
For a small collection, an unmodifiable view is enough and costs nothing extra. Return a real copy only when callers need their own independently mutable version. Never return the field itself, because that hands away the guarantee encapsulation exists to provide.
When is a public field acceptable?
For constants declared public static final, since the value cannot change and the guarantee matches a getter. Also for brief data holders confined to one package, where there are no external callers to protect. For anything with a lifetime beyond the local scope, use private fields.
How does encapsulation relate to the final keyword?
They address different risks. Encapsulation stops outsiders from reaching fields, while final stops any code, including the class itself, from reassigning them after initialisation. Together with constructor validation they produce a fully immutable object, which is the safest shape available.
Do records follow good encapsulation practice?
Yes. A record declares its components private and final, exposes them through accessors, and provides no setters, so instances are immutable by construction. For plain data with no invariants beyond the field values, they are usually better than a hand-written class with getters.