O que é design by contract?

Question

Accepted Answer

**Design by Contract (DbC)** trata a relação entre um método e seu chamador como um acordo formal, definido por três coisas: **precondições** (o que o chamador deve garantir), **postcondições** (o que o método garante em troca), e **invariantes** (o que permanece verdadeiro para o objeto em todos os momentos).

## As três obrigações

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

## Em código

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

Se uma *precondição* falha, o **chamador** tem o bug. Se uma *postcondição* ou *invariante* falha, o **método** tem o bug — contratos apontam culpa com precisão.

## Relação com LSP

DbC torna Liskov preciso: um subtipo pode **enfraquecer precondições** e **fortalecer postcondições**, mas nunca o inverso. Essa é exatamente a regra de substituibilidade, expressa como contratos.

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

## Por que isso importa

Contratos transformam suposições vagas ("valor deve ser positivo, acho que sim") em regras explícitas e verificáveis — e atribuem culpa com precisão quando algo quebra.

Eles fundamentam a substituição de Liskov e o design robusto de API: o contrato de um método é sua verdadeira interface, mais honesto do que apenas sua assinatura de tipo.