डिज़ाइन बाय कॉन्ट्रैक्ट क्या है?

Question

Accepted Answer

**Design by Contract (DbC)** एक पद्धति और उसके कॉलर के बीच संबंध को एक औपचारिक समझौते के रूप में मानता है, जो तीन चीजों द्वारा परिभाषित है: **पूर्व शर्तें** (जो कॉलर को गारंटी देनी चाहिए), **बाद की शर्तें** (जो पद्धति बदले में गारंटी देती है), और **अपरिवर्तनीय** (जो वस्तु के लिए हमेशा सच रहते हैं)।

## तीन दायित्व

```text
PRECONDITION  → caller's duty: inputs/state the method requires to run correctly
POSTCONDITION → method's duty: what it promises on return (if precondition held)
INVARIANT     → always-true property of the object, before and after every method
```

## In code

```python
class Account:
    def __init__(self, balance):
        self._balance = balance
        self._check_invariant()

def withdraw(self, amount):
        assert amount > 0, "PRE: amount must be positive"        # precondition
        assert amount <= self._balance, "PRE: sufficient funds"  # precondition
        old = self._balance
        self._balance -= amount
        assert self._balance == old - amount, "POST: balance reduced"  # postcond
        self._check_invariant()

def _check_invariant(self):
        assert self._balance >= 0, "INVARIANT: balance never negative"
```

अगर *पूर्व शर्त* विफल हो जाती है, तो **कॉलर** के पास बग है। अगर *बाद की शर्त* या *अपरिवर्तनीय* विफल हो जाते हैं, तो **पद्धति** के पास बग है — अनुबंध दोष को सटीक रूप से इंगित करते हैं।

## Relationship to LSP

DbC लिस्कोव को सटीक बनाता है: एक उप-प्रकार **पूर्व शर्तों को कमजोर** कर सकता है और **बाद की शर्तों को मजबूत** कर सकता है, लेकिन कभी नहीं, इसके विपरीत। यह ठीक विकल्पशीलता नियम है, अनुबंध के रूप में बताया गया है।

## Trade-offs

```text
✓ Bugs surface at the boundary, with clear blame   ✓ Contracts double as documentation
⚠️ Runtime checks cost performance (often disabled in prod via assertions)
⚠️ Not all languages enforce it natively (Eiffel does; most use asserts/validation)
```

## इससे क्यों मायने रखता है

अनुबंध अस्पष्ट मान्यताओं ("राशि सकारात्मक होनी चाहिए, मुझे लगता है") को स्पष्ट, जांचने योग्य नियमों में बदल देते हैं — और जब कुछ टूट जाता है तो वे दोष को सटीक रूप से निर्दिष्ट करते हैं।

वे लिस्कोव प्रतिस्थापन और मजबूत API डिजाइन का आधार बनते हैं: एक पद्धति का अनुबंध उसका वास्तविक इंटरफेस है, केवल इसके प्रकार हस्ताक्षर की तुलना में अधिक ईमानदार।