Mikor használjon getter és setter metódusokat (és mikor ne)?

Question

Accepted Answer

A getters/setters ellenőrzött hozzáférést biztosítanak a mezőkhöz, de az *minden mezőhöz* egy hozzáadásának szokásos szokása anti-pattern. A valódi kérdés az: az accessor értéket ad, vagy csak újra felicsomagol egy nyilvános mezőt extra lépésekkel?

## Amikor a setter indokolt

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

Itt a setter kikényszerít egy invarianciát — ez megéri az árát.

## Amikor csak zaj

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

## Jobb gondolkodásmód: mondd meg, ne kérdezz

Az állapot felismerése helyett, hogy a hívók manipuláljuk, ismertess *viselkedést*:

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

## Miért számít ez

Egy setter minden mezőn alig jobb, mint a mezőt nyilvánossá tenni — hamis behatárolás illúzióját adja, miközben bármely hívó szabadon mutálhatja az állapotot.

A viselkedés körül tervezés ("mondd meg, ne kérdezz") az objektumban tartja az invarianciákat, csökkenti a csatolódást, és gyakran feltárja, hogy sok mező immutábilis kellene legyen, és egyáltalán nem kellene setterje.