आप getters और setters का कब उपयोग करें (और कब नहीं)?

Question

Accepted Answer

Getters/setters fields तक नियंत्रित पहुंच प्रदान करते हैं, लेकिन *हर field* के लिए एक जोड़ने की आम आदत एक anti-pattern है। असली सवाल यह है: क्या accessor value जोड़ता है, या बस एक public field को अतिरिक्त steps के साथ फिर से expose करता है?

## जब setter justified हो

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

यहाँ setter एक invariant लागू करता है — यह इसके लायक है।

## जब वे सिर्फ noise हों

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

## एक बेहतर mindset: tell, don't ask

Callers के लिए state को expose करके manipulate करने की बजाय, *behavior* expose करें:

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

## यह क्यों महत्वपूर्ण है

हर field पर setter field को public बनाने से मुश्किल से बेहतर है — यह encapsulation का झूठा अहसास देता है जबकि कोई भी caller freely state को mutate कर सकता है।

Behavior के चारों ओर design करना ("tell, don't ask") invariants को object के अंदर रखता है, coupling कम करता है, और अक्सर ये पता चलता है कि कई fields immutable होनी चाहिए और कोई setter बिल्कुल नहीं होना चाहिए।