When should you use getters and setters (and when not)?

Question

Accepted Answer

Getters/setters expose controlled access to fields, but the common habit of adding one *for every field* is an anti-pattern. The real question is: does the accessor add value, or just re-expose a public field with extra steps?

## When a setter is justified

```java
public class Thermostat {
    private int target;
    public void setTarget(int t) {     // setter adds VALIDATION
        if (t < 5 || t > 30)
            throw new IllegalArgumentException("out of range");
        this.target = t;
    }
    public int getTarget() { return target; }
}
```

Here the setter enforces an invariant — that's worth its weight.

## When they're just noise

```java
// Anti-pattern: "encapsulation theatre"
public class Point {
    private int x, y;
    public int getX() { return x; }    public void setX(int x){ this.x=x; }
    public int getY() { return y; }    public void setY(int y){ this.y=y; }
}
// This is no safer than public fields — and now x,y can change anytime.
```

## A better mindset: tell, don't ask

Instead of exposing state for callers to manipulate, expose *behavior*:

```java
account.withdraw(100);          // ✅ behavior protects the rule
// vs
account.setBalance(account.getBalance() - 100);  // ❌ logic leaks to caller
```

## Why it matters

A setter on every field is barely better than making the field public — it gives a false sense of encapsulation while letting any caller mutate state freely.

Designing around behavior ("tell, don't ask") keeps invariants inside the object, reduces coupling, and often reveals that many fields should be immutable with no setter at all.