Mikä on Design by Contract?

Question

Accepted Answer

**Design by Contract (DbC)** käsittelee methodin ja sen kutsujan välistä suhdetta muodollisena sopimuksena, joka määritellään kolmella asialla: **preconditions** (mitä kutsuja on velvollinen takaamaan), **postconditions** (mitä method takaa vastineeksi), ja **invariants** (mitä pysyy totta objektille kaikissa tapauksissa).

## Kolme velvoitetta

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

## Koodissa

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

Jos *precondition* epäonnistuu, **kutsujalla** on virhe. Jos *postcondition* tai *invariant* epäonnistuu, **methodilla** on virhe — sopimukset osoittavat vastuun tarkasti.

## Suhde LSP:hen

DbC tekee Liskovin tarkkaa: alityyppi voi **heikentää preconditions** ja **vahvistaa postconditions**, mutta ei koskaan päinvastoin. Se on täsmälleen korvattavuussääntö, ilmaistu sopimuksina.

## Kompromissit

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

## Miksi se on tärkeää

Sopimukset muuttavat epäselvästi oletuslausunnot ("summan pitäisi olla positiivinen, luulen") eksplisiiteiksi, tarkistettaviksi säännöiksi — ja ne määrittävät vastuun tarkasti, kun jotain hajoaa.

Ne tukevat Liskov-korvattavuutta ja vahvaa API-suunnittelua: methodin sopimus on sen todellinen rajapinta, rehellisempi kuin pelkkä type signature.