Encapsulation interview questions, with answers

The questions, with answers

1. 1.What is encapsulation, and how is it different from abstraction?

   Encapsulation is bundling data with the methods that operate on it and restricting direct access to that data, so the object controls how its state changes. Abstraction is showing only what a caller needs and hiding how it is done — a List interface exposes add and get and hides whether there is an array or a chain of nodes underneath. They are complementary, not synonyms: encapsulation is enforced with access modifiers on the implementation; abstraction is expressed through interfaces and abstract classes at the design level. The neat line for the interview: abstraction hides complexity, encapsulation hides state — and abstraction is only safe because encapsulation stops callers reaching around it.

2. 2.Is data hiding the same thing as encapsulation?

   Data hiding is one result of encapsulation, not the whole of it. Encapsulation is the packaging — state and behaviour in one unit with a controlled boundary. Data hiding is the specific practice of making that state inaccessible from outside, usually with private fields. You can have encapsulation without much hiding (a struct-like class whose fields are public but whose behaviour lives with it) and hiding without good encapsulation (private fields with a setter for every one, so callers still manipulate the state piece by piece). The design goal is that the class alone can put itself into an invalid state — every other object has to go through methods that refuse to.

3. 3.Aren't getters and setters just public fields with extra steps?

   If every field has a trivial getter and setter, yes — nothing is protected, and the boilerplate hides that fact. The value appears when the accessor does something: a setter validates (age cannot be negative, a withdrawal cannot exceed the balance), a getter computes or converts, a field is exposed read-only by having a getter and no setter, or the internal representation changes — a price stored in paise instead of rupees — without touching any caller. A public field can never do any of those later without breaking every user. So write accessors for what the object promises, not one per field; a class with five fields and two public methods is usually better encapsulated than one with ten accessors.

4. 4.How can a getter break encapsulation even though the field is private?

   By returning the internal object itself. If a Team keeps a private List<Player> and getPlayers() returns that list, any caller can add or clear players without going through the Team, and the private keyword protected nothing. Mutable objects — collections, arrays, java.util.Date, StringBuilder — are all vulnerable. The fixes: return an unmodifiable view (Collections.unmodifiableList), return a defensive copy, or return an immutable type in the first place. The same leak happens in reverse in a setter or constructor that stores a mutable argument without copying it: the caller still holds a reference and can change your state later.

   public List<Player> getPlayers() {
       return Collections.unmodifiableList(players);   // callers can read, not mutate
   }
   
   public Team(List<Player> initial) {
       this.players = new ArrayList<>(initial);         // copy in; the caller's list is no longer ours
   }

5. 5.How do you write an immutable class, and what does it have to do with encapsulation?

   Make the class final so it cannot be subclassed into mutability, make every field private and final, set them all in the constructor, provide no setters, and defensively copy any mutable object on the way in and on the way out. String, Integer and LocalDate are built this way. Immutability is encapsulation taken to its limit: the state cannot be changed by anyone, so there is no invalid state to guard against after construction. The payoffs are practical — immutable objects are safe to share between threads without locks, safe as map keys, and trivially cacheable — which is why the question comes up in backend interviews as well as OOP rounds.

6. 6.How is encapsulation done in Python or JavaScript, which have no access modifiers?

   By convention and by language features that arrived later. In Python a single leading underscore marks an attribute as internal — nothing enforces it, but linters and reviewers treat it as private. A double underscore triggers name mangling (__balance becomes _Account__balance), which stops accidental access and subclass collisions but is still reachable on purpose. The @property decorator lets a plain-looking attribute run getter and setter code, so you can add validation later without changing callers. JavaScript classes gained truly private fields with the # prefix (#balance), enforced by the engine; before that, closures over local variables were the standard way to hide state. The point to make: encapsulation is a design discipline, and access modifiers are just one way to enforce it.

7. 7.What does "tell, don't ask" mean?

   Ask an object to do something rather than asking for its data and doing the work yourself. Code that reads account.getBalance(), checks it, then calls account.setBalance(balance - amount) has moved the withdrawal rule out of Account and into every caller, so each caller can get it wrong and the invariant is unenforceable. account.withdraw(amount) keeps the rule in one place, can reject the request, and lets Account change how it stores the balance. The principle is the behavioural side of encapsulation: private fields stop callers reaching in, and tell-don't-ask stops them needing to. If you find yourself writing a getter only so another class can make a decision about the object, the decision probably belongs in a method on that object.

8. 8.What is the Law of Demeter, and how does it relate to encapsulation?

   "Only talk to your immediate friends": a method should call methods on its own object, its parameters, objects it creates, and its direct components — not on objects it obtains by walking through others. A chain like order.getCustomer().getAddress().getCity() couples the caller to three classes' internals; if Address changes, code that only wanted a city breaks. Providing order.shippingCity() keeps the knowledge of that structure inside Order. It is encapsulation applied across objects rather than within one: every getter in the chain is a hole in a boundary, and the law says to stop drilling through them. The usual caveat is that fluent builders and stream pipelines look like chains but return the same object or a new value, so they do not violate it.

How the diagnostic asks it

One question from the OOP bank, exactly as a sitting would show it. The bank has 4 on encapsulation and 60 across OOP.