Khi nào nên dùng getter và setter (và khi nào không)?

Question

Accepted Answer

Getter/setter phơi bày quyền truy cập có kiểm soát tới các field, nhưng thói quen phổ biến là thêm một cặp *cho mỗi field* lại là một anti-pattern. Câu hỏi thực sự là: accessor có thêm giá trị, hay chỉ tái-phơi-bày một field public với vài bước thừa?

## Khi nào một setter là chính đáng

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

Ở đây setter thực thi một bất biến — điều đó đáng giá.

## Khi nào chúng chỉ là tạp âm

```java
// Anti-pattern: "diễn kịch encapsulation"
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; }
}
// Cái này chẳng an toàn hơn field public — và giờ x,y có thể đổi bất cứ lúc nào.
```

## Một tư duy tốt hơn: tell, don't ask (sai khiến, đừng hỏi)

Thay vì phơi bày trạng thái cho bên gọi thao tác, hãy phơi bày *hành vi*:

```java
account.withdraw(100);          // ✅ hành vi bảo vệ quy tắc
// so với
account.setBalance(account.getBalance() - 100);  // ❌ logic rò rỉ ra bên gọi
```

## Tại sao điều này quan trọng

Một setter cho mọi field chỉ nhỉnh hơn việc để field public một chút — nó tạo cảm giác encapsulation giả tạo trong khi cho phép bất kỳ bên gọi nào tự do thay đổi trạng thái.

Thiết kế xoay quanh hành vi ("tell, don't ask") giữ các bất biến bên trong object, giảm coupling, và thường hé lộ rằng nhiều field nên là immutable mà không cần setter nào cả.