ما هو التصميم بالعقد؟

Question

Accepted Answer

**التصميم بالعقد (DbC)** يعامل العلاقة بين method وطالبه كاتفاقية رسمية، معرّفة بثلاثة أشياء: **preconditions** (ما يجب على الطالب أن يضمنه)، **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*، فإن **الطالب** لديه الخطأ. إذا فشل *postcondition* أو *invariant*، فإن **method** لديه الخطأ — العقود توضح الذنب بدقة.

## العلاقة بـ LSP

DbC يجعل Liskov دقيقًا: قد يضعّف نوع مشتق **preconditions** ويقوّي **postconditions**، لكن ليس العكس. هذا هو بالضبط قاعدة القابلية للاستبدال، مُعبّر عنها كعقود.

## المقايضات

```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 والتصميم المتين للـ API: عقد method هو واجهته الحقيقية، أكثر صراحة من توقيعه الفقط.