¿Cuándo deberías usar getters y setters (y cuándo no)?

Question

Accepted Answer

Los getters/setters proporcionan acceso controlado a los campos, pero la costumbre común de agregar uno *a cada campo* es un anti-patrón. La pregunta real es: ¿el accesor añade valor, o simplemente re-expone un campo público con pasos adicionales?

## Cuándo un setter es 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; }
}
```

Aquí el setter impone una invariante — eso vale la pena.

## Cuándo son solo ruido

```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 mejor mentalidad: di, no preguntes

En lugar de exponer el estado para que los llamadores lo manipulen, expón *comportamiento*:

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

## Por qué es importante

Un setter en cada campo es apenas mejor que hacer el campo público — da una falsa sensación de encapsulación mientras permite que cualquier llamador mute el estado libremente.

Diseñar alrededor del comportamiento ("di, no preguntes") mantiene los invariantes dentro del objeto, reduce el acoplamiento y a menudo revela que muchos campos deberían ser inmutables sin setter alguno.