Wann sollten Sie Getters und Setters verwenden (und wann nicht)?

Question

Accepted Answer

Getters/Setters ermöglichen kontrollierten Zugriff auf Felder, aber die häufige Gewohnheit, einen *für jedes Feld* hinzuzufügen, ist ein Anti-Pattern. Die eigentliche Frage ist: Bietet der Accessor einen Mehrwert, oder stellt er nur ein öffentliches Feld mit zusätzlichen Schritten erneut zur Verfügung?

## Wenn ein Setter gerechtfertigt ist

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

Hier erzwingt der Setter eine Invariante — das lohnt sich.

## Wenn sie nur Rauschen sind

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

## Eine bessere Denkweise: Sage, frage nicht

Anstatt den Status freizulegen, damit Aufrufer ihn bearbeiten können, legen Sie *Verhalten* frei:

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

## Warum es wichtig ist

Ein Setter für jedes Feld ist kaum besser als ein öffentliches Feld — es gibt ein falsches Gefühl der Kapselung, während es jedem Aufrufer ermöglicht, den Status frei zu mutieren.

Das Design um Verhalten herum ("Sage, frage nicht") hält Invarianten im Objekt, reduziert Koppelung und offenbart oft, dass viele Felder unveränderlich sein sollten und überhaupt keinen Setter haben.