Quand devez-vous utiliser les getters et setters (et quand ne pas les utiliser) ?

Question

Accepted Answer

Les getters/setters exposent un accès contrôlé aux champs, mais l'habitude courante d'en ajouter *pour chaque champ* est un anti-pattern. La véritable question est : l'accesseur ajoute-t-il de la valeur, ou réexpose-t-il simplement un champ public avec des étapes supplémentaires ?

## Quand un setter est justifié

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

Ici, le setter applique un invariant — cela en vaut la peine.

## Quand c'est juste du bruit

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

## Une meilleure mentalité : ordonnez, ne demandez pas

Au lieu d'exposer l'état pour que les appelants le manipulent, exposez le *comportement* :

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

## Pourquoi c'est important

Un setter sur chaque champ n'est guère mieux que de rendre le champ public — cela donne une fausse impression d'encapsulation tout en permettant à n'importe quel appelant de muter l'état librement.

Concevoir autour du comportement (« ordonnez, ne demandez pas ») maintient les invariants à l'intérieur de l'objet, réduit le couplage et révèle souvent que de nombreux champs devraient être immuables sans setter du tout.