DSAMotivator

Encapsulation

OOP · 9 interview questions

Encapsulation is the practice of keeping an object's data and the methods that operate on that data together, while restricting direct access to the data from outside. The point is not secrecy — it's that an object gets to enforce its own rules.

The usual textbook example is a bank account with a private balance and a deposit method. The real argument is narrower: if any code anywhere can set balance directly, then every invariant you care about (balance never negative, every change is logged) has to be re-checked at every call site. Make the field private and there is exactly one place that can break it.

Interviewers press on this because most people can recite the definition and then immediately write a class with a public setter for every field — which is the same as making the fields public, just with more typing.

Encapsulation interview questions

What is encapsulation?
Bundling data with the methods that operate on it, and restricting direct access to that data from outside the object. The object controls how its own state changes.
Why they ask: The opening question. Getting the 'controls its own state' half in matters more than the bundling half.
How is encapsulation different from abstraction?
Abstraction is about design — deciding what to expose and hiding the complexity behind it. Encapsulation is about implementation — using access control to enforce that decision. Abstraction is the 'what', encapsulation is the 'how'.
Why they ask: The most common follow-up, and the one most people fumble. They overlap, so name the design/implementation split.
Does adding a getter and setter for every private field give you encapsulation?
No. A public setter for every field exposes the same mutable state as a public field would, just indirectly. Real encapsulation means exposing operations that preserve invariants (deposit, withdraw) rather than raw field access.
Why they ask: This is the question that separates memorised definitions from understanding.
What is a class invariant, and what does encapsulation have to do with it?
A condition that must always hold for an object to be valid — a balance that is never negative, a list whose size always matches its contents. Encapsulation makes invariants enforceable by ensuring all state changes go through code that checks them.
What are the usual access levels, from most to least restrictive?
private (this class only), package/internal (this package or assembly), protected (this class and subclasses), public (anywhere). Exact names and rules vary by language — Java's protected also allows package access; C++'s does not.
Why they ask: Say the caveat. Interviewers notice when someone states Java rules as universal.
How does Python do encapsulation without private fields?
By convention rather than enforcement. A leading underscore marks something as internal, and a double underscore triggers name mangling, which discourages access but does not prevent it. Python's position is that a determined caller can always reach in, so the language documents intent instead of blocking it.
Why they ask: A good answer here shows you understand encapsulation as a design idea rather than a keyword.
How does immutability relate to encapsulation?
An immutable object is the strongest form — if state can never change after construction, there are no invalid transitions to guard against. It removes a whole class of bugs, at the cost of allocating a new object for every change.
How can a getter break encapsulation even without a setter?
By returning a reference to internal mutable state. If getItems() hands back the actual list, callers can modify it directly and bypass every check the class performs. Return a copy or an unmodifiable view instead.
Why they ask: A favourite trap question — most candidates assume 'no setter' means safe.
Name a concrete benefit of encapsulation beyond 'it's good practice'.
You can change the internal representation without touching callers. If balance moves from a double to a currency object, code calling deposit() is unaffected — code that read the field directly is not.

You'll forget most of this by next week

That's not a discipline problem, it's how memory works. In the app these come back on an expanding schedule — right before you'd lose them.

Start free for 7 days