Quando você deve usar getters e setters (e quando não)?

Question

Accepted Answer

Getters/setters expõem acesso controlado a campos, mas o hábito comum de adicionar um *para cada campo* é um anti-padrão. A questão real é: o accessor agrega valor, ou apenas reexpõe um campo público com passos extras?

## Quando um setter é justificado

```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; }
}
```

Aqui o setter impõe um invariante — isso vale a pena.

## Quando são apenas ruído

```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.
```

## Uma melhor mentalidade: diga, não pergunte

Em vez de expor estado para que chamadores manipulem, exponha *comportamento*:

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

## Por que isso importa

Um setter em cada campo é pouco melhor do que tornar o campo público — dá uma falsa sensação de encapsulamento enquanto permite que qualquer chamador mute o estado livremente.

Projetar em torno de comportamento ("diga, não pergunte") mantém invariantes dentro do objeto, reduz acoplamento e frequentemente revela que muitos campos deveriam ser imutáveis sem setter algum.