Data Hiding vs Abstraction

Data hiding is about the inside of one object. Abstraction is about the boundary between a caller and a collaborator. In the code above the internal list in ArrayStack is data hiding, because it is private and no caller can reach it. The Stack interface is abstraction, because it describes four operations without saying that the implementation happens to use a list.

public class Main {
    public static void main(String[] args) {
        Stack stack = new ArrayStack();
        stack.push("a");
        stack.push("b");
        System.out.println(stack.size());
        System.out.println(stack.peek());
        System.out.println(stack.pop());
        System.out.println(stack.size());
    }
}

interface Stack {
    void push(String value);
    String pop();
    String peek();
    int size();
}

class ArrayStack implements Stack {
    private final java.util.List<String> items = new java.util.ArrayList<>();
    public void push(String value) { items.add(value); }
    public String pop() { return items.remove(items.size() - 1); }
    public String peek() { return items.get(items.size() - 1); }
    public int size() { return items.size(); }
}

The output shows the value of having both. The caller pushes, peeks, pops and counts, and never learns that the implementation stores items in an ArrayList. If you later swapped that for a linked structure or for a database-backed implementation, the caller would not change, and the private list would simply be replaced.

Another way to see the difference is to ask what happens when the abstraction is missing. With data hiding but no abstraction, callers would depend on the concrete ArrayStack type, so swapping the implementation becomes a change across the codebase. With abstraction but no data hiding, the contract might be fine but the internals would be open to anyone, so nothing could enforce the rules.

The pairing is what makes change cheap. Data hiding lets you change the inside; abstraction stops the change from spreading. Used together, they are the practical core of object-oriented design.

No, they operate at different levels and solve different problems. Data hiding protects the contents of an object from outside code. Abstraction reduces the amount of a component that outside code has to understand in the first place.

A concrete example of data hiding: a counter class keeps its count in a private field and only lets you increment it and read it. The count cannot be set to a nonsensical value from outside. A concrete example of abstraction: a notification interface with a single send method hides whether the delivery happens by email, SMS or a queue.

They are frequently implemented together and often confused, because both are described as hiding something and both rely on access modifiers. The distinguishing question is who is being protected. Data hiding protects the object from its callers. Abstraction protects the caller from the object.

One more angle that helps in an interview: data hiding is about state, abstraction is about complexity. You can hide data without offering any abstraction, in which case callers still know exactly how your class works internally. And you can offer a beautiful abstraction over exposed state, in which case the state is still everybody's business.