Kdaj bi moral uporabiti getters in setters (in kdaj ne)?

Question

Accepted Answer

Getters/setters omogočajo nadzorovan dostop do polj, vendar je pogosta navada dodajanja enega *za vsako polje* anti-vzorec. Pravo vprašanje je: ali getter/setter doda vrednost ali samo ponovno izpostavi javno polje z dodatnimi koraki?

## Kdaj je setter upravičen

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

Tu setter uveljavlja invarianto — to je vredno.

## Kdaj so samo hrup

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

## Boljši pristop: povedi, ne sprašuj

Namesto da izpostavljaš stanje, ki ga klicatelji manipulirajo, izpostavi *vedenje*:

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

## Zakaj je to važno

Setter na vsakem polju je le malo boljši od javnega polja — daje lažen občutek enkapsulacije, medtem ko dovoljuje vsakemu klicatelju prosto spreminjati stanje.

Oblikovanje okoli vedenja ("povedi, ne sprašuj") drži invariante znotraj objekta, zmanjšuje povezanost in pogosto razkrije, da bi morala biti številna polja nespremenljiva brez setterja.