Why Information Hiding Helps

The mechanism is dependency direction. When a caller can only reach a narrow contract, it does not compile against the parts of the implementation that are free to change. So when the implementation changes, the caller is untouched and does not even need to be recompiled in a meaningful sense. The cost of the change stays inside the class that owns the detail.

public class Main {
    public static void main(String[] args) {
        Report r = new Report();
        r.addLine("alpha");
        r.addLine("beta");
        System.out.println(r.render());
        System.out.println("lines = " + r.lineCount());
    }
}

class Report {
    private final java.util.List<String> lines = new java.util.ArrayList<>();
    void addLine(String line) { lines.add(line); }
    int lineCount() { return lines.size(); }
    String render() {
        StringBuilder sb = new StringBuilder();
        for (String line : lines) {
            sb.append("- ").append(line).append("\n");
        }
        return sb.toString();
    }
}

The report class is a small illustration. The internal list is private, and the caller can only add lines, count them and ask for a rendered string. Inside render, the implementation could switch from a list to an array, add indentation, or escape markup, and no caller would notice, because no caller ever saw the list.

The second benefit is about people rather than machines. Encapsulation means that a developer reading a caller does not have to read the implementation to understand what is happening, because the caller's view of the component is the contract and nothing more. That is why large systems stay navigable.

The third benefit is that it lets you change your mind. If the storage choice was hidden behind an interface, you can change it late in development, which is exactly when you have learned the most about the requirements. If it leaked, that same late change becomes a sweeping refactor.

The costs are real. Every layer of hiding adds indirection, so a value that would be one field access in a plain class becomes a method call through an interface, possibly through a wrapper. In a hot path that can matter. Hiding also adds files, adds places to look, and makes plain data harder to see, which is why some frameworks deliberately expose state for convenience and accept the coupling.

There is a subtle cost too: hiding forces you to design a contract before you know exactly what you need, and the contract becomes hard to change once callers depend on it. Over-hiding is the mirror image of the no-information-hiding failure, and it produces classes with a dozen one-line delegating methods.

Exposing an implementation detail makes sense in a few situations. For a value object with genuinely simple, always-consistent state, a public final field is clearer than a getter. For a debug view or a toString-style representation, exposing a read-only projection is fine. For a framework that must configure an object after construction, some setters are unavoidable, and the answer is to make them validating rather than to pretend the object is immutable.

The principle to give an interviewer is that the decision is about how likely the detail is to change and who is allowed to depend on it. A field that will never change and has no invariant is harmless to expose. A field that everything depends on is worth hiding until someone asks for it.