ডিজাইন বাই কন্ট্র্যাক্ট কি?

Question

Accepted Answer

**ডিজাইন বাই কন্ট্র্যাক্ট (DbC)** একটি method এবং এর caller এর মধ্যে সম্পর্ককে একটি আনুষ্ঠানিক চুক্তি হিসেবে বিবেচনা করে, যা তিনটি জিনিস দ্বারা সংজ্ঞায়িত: **preconditions** (caller কে যা নিশ্চিত করতে হবে), **postconditions** (method বিনিময়ে যা নিশ্চিত করে), এবং **invariants** (object এর জন্য সর্বদা যা সত্য থাকে)।

## তিনটি দায়িত্ব

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

## কোডে

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

যদি একটি *precondition* ব্যর্থ হয়, তাহলে **caller** এর ত্রুটি আছে। যদি একটি *postcondition* বা *invariant* ব্যর্থ হয়, তাহলে **method** এর ত্রুটি আছে — চুক্তি যখন কিছু ভেঙ্গে যায় তখন দোষ নির্ধারণ করে।

## LSP এর সাথে সম্পর্ক

DbC Liskov কে নির্ভুল করে তোলে: একটি subtype **preconditions** দুর্বল করতে পারে এবং **postconditions** শক্তিশালী করতে পারে, কিন্তু বিপরীতটা নয়। এটি ঠিক substitutability নিয়ম, চুক্তি হিসেবে বর্ণিত।

## ট্রেড-অফস

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

## কেন এটি গুরুত্বপূর্ণ

চুক্তি অস্পষ্ট ধারণাকে ("পরিমাণ ইতিবাচক হওয়া উচিত, আমি মনে করি") সুস্পষ্ট, পরীক্ষাযোগ্য নিয়মে রূপান্তরিত করে — এবং যখন কিছু ভেঙ্গে যায় তখন তারা নির্ভুলভাবে দোষ নির্ধারণ করে।

তারা Liskov substitution এবং শক্তিশালী API ডিজাইনকে সমর্থন করে: একটি method এর চুক্তি তার সত্যিকারের ইন্টারফেস, শুধুমাত্র তার type signature এর চেয়ে বেশি সৎ।