Quando dovrebbe usare getters e setters (e quando no)?

Question

Accepted Answer

I getter/setter espongono un accesso controllato ai campi, ma l'abitudine comune di aggiungerne uno *per ogni campo* è un anti-pattern. La vera domanda è: l'accessor aggiunge valore, o semplicemente ri-espone un campo public con passaggi extra?

## Quando un setter è giustificato

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

Qui il setter applica un'invariante — vale la pena.

## Quando sono solo rumore

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

## Una mentalità migliore: comunica, non chiedere

Invece di esporre lo stato perché i caller lo manipolino, esponi il *comportamento*:

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

## Perché è importante

Un setter su ogni campo è a malapena migliore di rendere il campo public — dà una falsa sensazione di incapsulamento mentre permette a qualsiasi caller di mutare lo stato liberamente.

Progettare attorno al comportamento ("comunica, non chiedere") mantiene le invarianti dentro l'oggetto, riduce l'accoppiamento, e spesso rivela che molti campi dovrebbero essere immutabili senza setter.