Getters, Setters and Invariants

Start from the rules the class promises, not from the fields it happens to have. If the promise is that a balance is never negative, then every path that writes a balance has to enforce it. A setter that validates is one such path. A deposit method that rejects non-positive amounts is another. Both funnel into the same private state, so there is no back door.

public class Main {
    public static void main(String[] args) {
        Account a = new Account("Ada", 100.0);
        a.setBalance(250.0);
        System.out.println("balance = " + a.balance());
        try {
            a.setBalance(-5.0);
        } catch (IllegalArgumentException e) {
            System.out.println("rejected: " + e.getMessage());
        }
        System.out.println("balance = " + a.balance());
    }
}

class Account {
    private final String owner;
    private double balance;
    Account(String owner, double balance) { this.owner = owner; setBalance(balance); }
    void setBalance(double value) {
        if (value < 0) {
            throw new IllegalArgumentException("negative balance");
        }
        balance = value;
    }
    double balance() { return balance; }
    void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("deposit must be positive");
        }
        balance += amount;
    }
}

The output shows the difference between enforcing and assuming. The valid write succeeds and the balance becomes 250.0. The invalid write is refused with a clear message, and a final read confirms the balance is still 250.0, so the rejected value never touched the object.

Notice the constructor also routes through the setter. That is deliberate, and it is the detail interviewers like to see: validation that lives in one place applies to every way of creating the object, including deserialisation and factory methods. If the constructor had assigned the field directly, the rule would have a gap in it.

The stronger move, when you can, is to remove the setter altogether. If balance should only ever increase, then a setBalance method is a hole in the design that a future caller will find and use. Offer deposit and withdraw, and there is no operation that can put the account into an invalid state.

No. A getter and a setter for every field is a classic smell, sometimes called an anemic domain model. The sign is that the class holds data and nothing else, while the real rules drift into service classes that operate on it. At that point the object is a data transfer wrapper and the domain has no home.

The other sign is a setter that does nothing but assign. A plain setter cannot validate anything, cannot maintain a related field, and cannot prevent a future misuse. It adds a line of code and a public promise that callers may write to the object in any state, which is exactly what encapsulation is supposed to prevent.

A getter is different, and much more defensible. Reading a value usually needs no special rules, and a read-only accessor is a clean way to expose state without exposing the storage. The smell there is returning a mutable structure, which leaks the internals just as badly as a public field would.

The rule of thumb to state in an interview: add a setter only when setting that value is a legitimate operation that the domain allows, and validate it there. Add a getter when reading is legitimate, and return a copy or an unmodifiable view if the underlying structure is mutable. Everything else should not be a public method at all.