Encapsulation Questions Explained

You cannot fully, which is the point worth making first. If a class exposes a setter for every field, any caller can put the object into a state the class never intended, so the class has to validate on every write. That means validation logic, error handling and defensive copies scattered across a lifecycle that should be simple.

The stronger design is to remove the write path entirely. Make the field private, expose no mutator, and change state only through operations that establish the invariant as a side effect. A balance cannot be set to a negative number because there is no setBalance method; there is a withdraw method that either succeeds or refuses. The invalid state has no path into the object.

Where you genuinely need to accept values, validate in one place rather than at each use. A constructor that rejects a negative amount, a check in the mutator that throws with a clear message, and a private copy of any mutable input so the caller cannot mutate the object afterwards. That last part, defensive copying, is the detail interviewers often probe: returning your internal list directly lets a caller change it without going through any of your logic.

Finally, prefer immutable objects where you can. If nothing can change after construction, there is no window in which the object is briefly invalid, no thread-safety question to answer, and the compiler can share references freely.

Encapsulating a class means bundling its data with the operations that are allowed to work on that data, and keeping the data itself private so the class remains the only thing that can change it. The public surface of the class becomes a set of operations, not a bag of values.

A public field gives you none of that. Anyone who holds a reference can write to it, so the object can end up in a state its own methods never anticipated. It also leaks the storage decision: change the field from an int to a computed value, or from a mutable list to an unmodifiable view, and every caller that touched the field breaks at once.

With encapsulation, the class can change how it stores things without breaking anyone, because the only thing callers rely on is the behaviour. It can add validation, add logging, add caching, or compute a value on demand, all without a single call site being edited. It can also decide that a value is read-only, so callers stop copying it defensively all over the codebase.

The trade-off to acknowledge is that encapsulation is not free. Every read and write goes through a method, and a class with a getter and setter for every field adds ceremony without adding protection. Good encapsulation means hiding the parts that need protecting and leaving the rest plainly visible.