언제 getter와 setter를 사용해야 하나요(그리고 언제 사용하지 말아야 하나요)?

Question

Accepted Answer

Getter/setter는 필드에 대한 통제된 접근을 노출하지만, *모든 필드에 하나씩* 추가하는 흔한 습관은 안티패턴입니다. 진짜 질문은: 이 접근자가 가치를 더하는가, 아니면 public 필드를 단지 추가 단계와 함께 다시 노출할 뿐인가?

## setter가 정당화될 때

```java
public class Thermostat {
    private int target;
    public void setTarget(int t) {     // setter 가 검증을 추가
        if (t < 5 || t > 30)
            throw new IllegalArgumentException("out of range");
        this.target = t;
    }
    public int getTarget() { return target; }
}
```

여기서 setter는 불변식을 강제합니다 — 그만한 가치가 있습니다.

## 단지 잡음일 때

```java
// 안티패턴: "캡슐화 연극"
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; }
}
// 이것은 public 필드보다 안전하지 않습니다 — 게다가 이제 x,y 가 언제든 변할 수 있습니다.
```

## 더 나은 사고방식: 묻지 말고 시켜라(tell, don't ask)

호출자가 조작하도록 상태를 노출하는 대신 *동작*을 노출하세요:

```java
account.withdraw(100);          // ✅ 동작이 규칙을 보호
// 대
account.setBalance(account.getBalance() - 100);  // ❌ 로직이 호출자로 새어 나감
```

## 왜 중요한가

모든 필드에 setter를 두는 것은 필드를 public으로 만드는 것보다 거의 나을 게 없습니다 — 어떤 호출자든 자유롭게 상태를 변경하게 하면서 encapsulation의 거짓된 안정감을 줍니다.

동작 중심 설계("묻지 말고 시켜라")는 불변식을 객체 내부에 유지하고, 결합도를 줄이며, 종종 많은 필드가 setter 없이 불변이어야 함을 드러냅니다.