Abstraction vs encapsulation interview questions, with answers

The questions, with answers

1. 1.Abstraction versus encapsulation: which problem does each one solve?

   In short: Abstraction decides what a caller needs to see, the operations; encapsulation decides who may change the state, the protection — one shapes the interface, the other guards the implementation.

   Picture a bank account class. Its abstraction is the set of things a caller can do — deposit, withdraw, check the balance — described without a word about how the balance is stored or how an overdraft is checked. Its encapsulation is the private balance field and the rule inside withdraw that refuses to take it below zero, so no caller can put the object into an invalid state. Abstraction is a design decision about the outside of a class; encapsulation is an implementation discipline about the inside. The one-liner 'abstraction hides complexity, encapsulation hides data' is not wrong, but it misses why each exists: abstraction lets callers ignore detail, and encapsulation lets the class enforce its own rules.

2. 2.Can you have abstraction without encapsulation, or encapsulation without abstraction?

   In short: Yes to both, and the two examples are the clearest way to show an interviewer that you understand the difference rather than the definitions.

   Abstraction without encapsulation: a C library that offers a clean set of stack functions but declares the stack's struct in a public header, so any caller can reach into the array and break it. The interface is a good abstraction; nothing enforces it. Encapsulation without abstraction: a Java class with every field private and a getter and a setter for each. Nothing changes except through methods, yet the methods simply mirror the fields, so every caller still depends on the representation — rename a field and the change spreads through the codebase. Good classes have both: a small set of meaningful operations, and state that only those operations can change.

3. 3.Which Java features implement abstraction, and which implement encapsulation?

   In short: Interfaces, abstract classes and well-chosen method signatures express abstraction; access modifiers, final fields and module exports enforce encapsulation.

   An interface is abstraction in its purest form: Map promises put and get, and HashMap and TreeMap keep their very different structures to themselves. An abstract class is abstraction with some shared implementation attached. Encapsulation is enforced by the access modifiers — private for state, package-private for helpers only the package should see — by final fields that cannot be reassigned, and, since Java 9, by modules that export some packages and keep the rest inaccessible. The features overlap in use: programming to an interface is abstraction, and it also encapsulates the choice of implementation class, because callers never name it. That overlap is worth saying if the interviewer pushes on which one an interface is.

4. 4.Is an abstract class the same thing as abstraction?

   In short: No: an abstract class is one language mechanism for expressing an abstraction, and a class can be abstract without being a good abstraction, or concrete and still be one.

   Abstraction is a design idea — show the essential, hide the rest — and it can be expressed through an interface, an abstract class, a single function with a clear contract, or a concrete class whose public methods say nothing about its internals. String is concrete and one of the best abstractions in Java; few callers know or care how it stores its characters. Going the other way, an abstract class that exposes protected fields for subclasses to modify directly is abstract in the language sense but leaks its internals to every subclass. When asked for 'abstraction in Java', answering 'abstract classes and interfaces' is fine as a start; add that these are the tools, and that the abstraction is the contract they describe.

5. 5.What is a leaky abstraction, and how does encapsulation help prevent one?

   In short: A leaky abstraction forces callers to know about the implementation it claims to hide; encapsulating that detail behind the interface's own types and errors plugs the leak.

   Suppose a UserStore interface has a method findUser that returns a java.sql.ResultSet and throws SQLException. The interface looks abstract, but every caller now handles database rows and database errors, and moving users to a file or a web service changes every call site. The fix is encapsulation at the boundary: return a User object, translate SQLException into the store's own exception type, and keep the connection and the queries private to the implementation. Joel Spolsky's 'law of leaky abstractions' observes that every non-trivial abstraction leaks to some degree — performance is the usual leak — so the goal is not zero leaks but leaks a caller can ignore until they measure.

6. 6.How would you show abstraction and encapsulation together in one small example?

   In short: Write an interface with just the operations a caller needs and one class that implements it with private state, then point at which part is which.

   In the code below the IntStack interface is the abstraction: push, pop and isEmpty, with no hint of an array. ArrayIntStack is the encapsulation: the array and the size are private, the array grows itself when full, and pop refuses to run on an empty stack, so no caller can corrupt the stack or read past its end. A caller written against IntStack keeps working if the implementation switches to linked nodes, which is the abstraction paying off; and no caller can set size to a negative number, which is the encapsulation paying off. Pushing 1, 2 and 3 and then popping three times returns 3, 2 and 1.

   interface IntStack {                   // abstraction: what callers may do
       void push(int x);
       int pop();
       boolean isEmpty();
   }
   
   class ArrayIntStack implements IntStack {
       private int[] data = new int[2];   // encapsulation: state only these methods touch
       private int size = 0;
   
       public void push(int x) {
           if (size == data.length) data = java.util.Arrays.copyOf(data, size * 2);
           data[size++] = x;
       }
       public int pop() {
           if (size == 0) throw new IllegalStateException("empty stack");
           return data[--size];
       }
       public boolean isEmpty() { return size == 0; }
   }

7. 7.What follow-up questions do interviewers ask about abstraction and encapsulation?

   In short: They move from definitions to classification — is a private method abstraction or encapsulation, where does an interface fit — and then ask for an example from your own work.

   Three come up often. Is a private helper method abstraction or encapsulation? Encapsulation, since it hides an implementation detail, and it also serves abstraction by keeping the public surface small. Is an interface abstraction or encapsulation? Abstraction first, encapsulation as a side effect, as described above. And a real-world analogy: a car's steering wheel and pedals are its abstraction, because a driver needs nothing more, while the sealed engine bay and the electronic limits on the engine are its encapsulation, because the driver cannot push the engine into a state that damages it. Have one example from a project of your own ready as well; interviewers weigh it more than any analogy.

8. 8.How do abstraction and encapsulation relate to information hiding?

   In short: Information hiding is the older, broader principle behind both: design each module to hide a decision that is likely to change, behind an interface that is not.

   David Parnas set out the principle in 1972, in a paper on the criteria for decomposing a system into modules: the boundary of a module should surround a design decision worth hiding, such as a data format or an algorithm, rather than a step in a flowchart. Abstraction is the interface half of that idea, what the module promises; encapsulation is the enforcement half, the language making sure nothing outside can depend on the hidden decision. Naming Parnas is not needed in a placement interview, but the framing is useful: when you design a class, ask which decision it hides, and whether a caller could still find it out.

How the diagnostic asks it

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