What is design by contract?

Question

Accepted Answer

**Design by Contract (DbC)** treats the relationship between a method and its caller as a formal agreement, defined by three things: **preconditions** (what the caller must guarantee), **postconditions** (what the method guarantees in return), and **invariants** (what stays true for the object at all times).

## The three obligations

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

If a *precondition* fails, the **caller** has the bug. If a *postcondition* or *invariant* fails, the **method** has the bug — contracts pinpoint blame.

## Relationship to LSP

DbC makes Liskov precise: a subtype may **weaken preconditions** and **strengthen postconditions**, but never the reverse. That's exactly the substitutability rule, stated as contracts.

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

## Why it matters

Contracts turn vague assumptions ("amount should be positive, I think") into explicit, checkable rules — and they assign blame precisely when something breaks.

They underpin Liskov substitution and robust API design: a method's contract is its true interface, more honest than its type signature alone.