What Is Encapsulation?

Encapsulation is the practice of keeping a class's data private and exposing only the operations that are allowed to work on it. The point is not secrecy for its own sake. It is that the class becomes the only thing that can change its own state, so the class itself is responsible for keeping that state valid.

public class Main {
    public static void main(String[] args) {
        Temperature t = new Temperature();
        t.setCelsius(21.5);
        System.out.println(t.celsius() + "C = " + t.fahrenheit() + "F");
        try {
            t.setCelsius(-500);
        } catch (IllegalArgumentException e) {
            System.out.println("rejected: " + e.getMessage());
        }
    }
}

class Temperature {
    private double celsius;
    void setCelsius(double value) {
        if (value < -273.15) {
            throw new IllegalArgumentException("below absolute zero");
        }
        celsius = value;
    }
    double celsius() { return celsius; }
    double fahrenheit() { return celsius * 9 / 5 + 32; }
}

The temperature class shows the mechanism. The field is private, so the only way in is the setter, and the setter rejects a value below absolute zero. The exception is thrown at the point of the bad write, so the invalid value never enters the object. A caller that tries gets an immediate, explanatory failure instead of a corrupted object that misbehaves later.

Notice that the class still offers everything a caller legitimately needs: reading the temperature in either unit, and setting a valid one. Encapsulation is not about hiding functionality. It is about routing every mutation through a place where the rules can be enforced.

The benefit shows up over time. If a rule changes, say the unit becomes Kelvin internally, you edit one class and every caller keeps working. If the field were public, every caller would have to be updated, and any caller that forgot would silently corrupt the object.

Three things, and the third is usually the most valuable. First, control: with a public field, any holder of a reference can write it, so the object can reach a state the class never intended. With a private field and a method, only the class decides what changes.

public class Main {
    public static void main(String[] args) {
        Counter c = new Counter();
        c.increment();
        c.increment();
        System.out.println(c.value());
    }
}

class Counter {
    private int count = 0;
    void increment() { count = count + 1; }
    int value() { return count; }
}

Second, validation and derived values. A method can refuse bad input, and it can compute something that never needed to be stored at all. A public field can only ever be a raw value that somebody else has to interpret correctly.

Third, and this is the one people miss, freedom to change the internals. The counter here could tomorrow be backed by a long, by an atomic wrapper, or by a service call, and the callers would not change at all. With a public field, the field is not just the value, it is the storage decision, and that decision becomes part of the contract with every caller.

The counter example shows the simplest version. The counter could have been incremented a hundred different ways, and the two calls to increment produce exactly the same observable result as a caller writing count = count + 1 directly, except that now the class owns the rule.

The trade-off worth mentioning is that a getter and setter for every field gives you the ceremony without the safety. The method is worth having when it does something: validating, computing, or logging.

Return a read-only view rather than the collection itself. The standard library gives you an unmodifiable wrapper, which produces a collection the caller can read and iterate but that throws if they try to add, remove or clear it. Crucially, the wrapper is a view of the live collection rather than a copy, so later additions made through your own methods are still reflected in what callers see.

That choice has a consequence you should be able to state: the caller sees current contents but never a path to mutate them. If you instead return a fresh copy each time, the caller gets a true snapshot and is fully insulated from later changes, at the cost of allocating on every call and of callers holding on to stale data.

There is a third option that combines both. Copy on write: return an unmodifiable copy to callers, but replace your internal collection whenever it changes. Callers then always get current contents, can never mutate what they received, and the only cost is a copy on each modification rather than on each read.

Remember that a read-only view is not deeply read-only. If the collection holds mutable objects, a caller can still mutate those objects through the view, and your class loses control of their state. For that case either copy the elements as well, or, much more commonly, require the element type to be immutable so there is nothing to mutate.

The interview summary is that access modifiers and return types work together. Private fields stop callers reaching the state directly, and a carefully chosen return type stops them reaching it by another route.