Hvornår bør du bruge getters og setters (og hvornår ikke)?

Question

Accepted Answer

Getters/setters giver kontrolleret adgang til felter, men den almindelige vane med at tilføje en *til hvert felt* er et anti-pattern. Det rigtige spørgsmål er: tilføjer accessoren værdi, eller genudstiller den bare et offentligt felt med ekstra trin?

## Når en setter er berettiget

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

Her håndhæver setteren en invariant — det er værd at tillade.

## Når de bare er støj

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

## En bedre mentalitet: fortæl, spørg ikke

I stedet for at udstille tilstand for kaldeprogram til at manipulere, udstil *adfærd*:

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

## Hvorfor det betyder noget

En setter på hvert felt er næppe bedre end at gøre feltet offentligt — det giver en falsk følelse af indkapsling, mens det tillader enhver kalder at mutere tilstand frit.

At designe omkring adfærd ("fortæl, spørg ikke") holder invarianter inden for objektet, reducerer koblingen og afslører ofte, at mange felter bør være uforanderlige uden setter overhovedet.