What Is Encapsulation and Why Bother?

Encapsulation means keeping an object's state private and controlling every change to it through methods the class itself provides. The point is not the getters and setters — it is that the class, and only the class, decides what a valid state is.

A public field has no such guarantee. Anyone can write a nonsensical value and the object has no way to react. Once the field is private and every write goes through a method, you can validate the value, normalise it, keep a derived field in step, or log the change — and you can do all of that later without touching a single caller.

public class Main {
    public static void main(String[] args) {
        Temperature t = new Temperature();
        t.setCelsius(25.0);
        System.out.println("celsius   : " + t.getCelsius());
        System.out.println("fahrenheit: " + t.getFahrenheit());

        // The setter rejects invalid input instead of storing it.
        try {
            t.setCelsius(-500.0);
        } catch (IllegalArgumentException e) {
            System.out.println("rejected  : " + e.getMessage());
        }
        System.out.println("unchanged : " + t.getCelsius());
    }
}

class Temperature {
    private double celsius;

    public double getCelsius() {
        return celsius;
    }

    public void setCelsius(double celsius) {
        if (celsius < -273.15 || celsius > 1000) {
            throw new IllegalArgumentException("out of range: " + celsius);
        }
        this.celsius = celsius;
    }

    public double getFahrenheit() {
        return celsius * 9 / 5 + 32;
    }
}

The output shows what encapsulation buys. The bad value never reaches the field, so the object is still valid after the failed call, and the derived Fahrenheit reading can be computed from the single stored value instead of being a second field that could drift out of sync.

The counter-argument you will hear is that getters and setters are boilerplate that adds no safety. That is fair when they are pure accessors, and it is why the modern advice is to write accessors only when they earn their place — a validating setter, a computed getter, or a getter that returns a defensive copy. Java records and Lombok both exist because hand-writing trivial accessors is tedious, and both are reasonable answers to that objection.

They operate at opposite ends of the visibility spectrum. Abstraction is about what a type offers: it hides how something works behind a contract. Encapsulation is about what a type protects: it hides its internal state so the state stays valid.

Concretely, abstraction shows up in the signature of a type. A caller who holds a List does not know or care that it is backed by an array, that it grows by doubling, or that its iterator is fail-fast. That is abstraction: the mechanism is replaceable and the caller is insulated from it.

Encapsulation shows up in the fields and the accessors. The class declares its fields private and exposes operations instead of data, so that every mutation goes through code that can enforce a rule. You can see the difference in what happens when a rule is broken: with poor encapsulation the object silently holds an impossible value; with good encapsulation the call is rejected and the object remains consistent.

The two combine in the classic shape. An abstract base class or an interface states the contract — the abstraction — and the concrete implementation keeps its state private and validates every change — the encapsulation. Neither implies the other: a plain data class can be perfectly encapsulated with a trivial interface, and an interface can be a useful abstraction over an implementation that leaks its internals.

A useful test in an interview: ask whether you could change the implementation without breaking callers. If yes, you have abstraction. Ask whether you could add a validation rule without breaking callers. If yes, you have encapsulation.

Put the rule where the state changes, and make the state unreachable except through that path. In practice that means private fields, and every write performed by a method that checks the rule first. Then an invalid object cannot be constructed, because the constructor validates too.

There are three levels of strictness, and the right one depends on what the class represents. A lenient setter validates and throws an IllegalArgumentException on bad input, leaving the object untouched. A defensive setter silently ignores or clamps the bad value. And the strictest option is to have no setter at all: the state changes only through operations that are meaningful for the domain, such as withdraw and deposit, and the balance is never set directly at all.

public class Main {
    public static void main(String[] args) {
        Account a = new Account("Ada", 100);
        System.out.println("created : " + a);

        try {
            a.setBalance(-50);
        } catch (IllegalArgumentException e) {
            System.out.println("rejected: " + e.getMessage());
        }
        System.out.println("balance : " + a.getBalance());

        try {
            a.withdraw(500);
        } catch (IllegalStateException e) {
            System.out.println("rejected: " + e.getMessage());
        }
        System.out.println("balance : " + a.getBalance());
    }
}

class Account {
    private final String owner;
    private long balance;

    Account(String owner, long balance) {
        if (balance < 0) {
            throw new IllegalArgumentException("opening balance cannot be negative");
        }
        this.owner = owner;
        this.balance = balance;
    }

    public String getOwner() {
        return owner;
    }

    public long getBalance() {
        return balance;
    }

    public void setBalance(long balance) {
        if (balance < 0) {
            throw new IllegalArgumentException("balance cannot be negative");
        }
        this.balance = balance;
    }

    public void withdraw(long amount) {
        if (amount > balance) {
            throw new IllegalStateException("insufficient funds");
        }
        this.balance -= amount;
    }

    @Override
    public String toString() {
        return owner + " with " + balance;
    }
}

Note the choice of exception types: IllegalArgumentException for a value that is wrong in itself, and IllegalStateException for an operation that is not allowed given the current state. Getting that distinction right matters, because callers legitimately handle the two differently.

The output shows the invariant holding through both rejections. If you go further and remove the setter entirely — leaving only deposit and withdraw — the invalid state becomes unrepresentable rather than merely prevented, which is the strongest form of the same idea and the direction modern Java pushes with records and sealed types.