Mi az Design by Contract?

Question

Accepted Answer

**Design by Contract (DbC)** egy metódus és hívója közötti kapcsolatot formális szerződésként kezeli, amely három dologgal van meghatározva: **előfeltételek** (amit a hívónak garantálnia kell), **utófeltételek** (amit a metódus viszonzásul garantál), és **invariánsok** (amit az objektum számára mindig igaz marad).

## A három kötelezettség

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

Ha az *előfeltétel* nem teljesül, a **hívónak** van hibája. Ha az *utófeltétel* vagy *invariáns* nem teljesül, a **metódusnak** van hibája — a szerződések pontosan meghatározzák a felelősséget.

## Relationship to LSP

A DbC pontos Liskov: egy altípus **gyengítheti az előfeltételeket** és **erősítheti az utófeltételeket**, de soha fordítva. Ez pontosan a helyettesíthetőségi szabály, szerződésekként kifejezve.

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

## Miért számít

A szerződések homályos feltételezéseket ("az összegnek pozitívnak kell lennie, azt gondolom") explicit, ellenőrizhető szabályokra alakítanak — és pontosan meghatározzák a felelősséget, amikor valami meghibásodik.

A Liskov-helyettesítés és a robusztus API-tervezés alapja: egy metódus szerződése annak valódi felülete, őszintébb, mint csak a típus aláírása.