Apakah itu design by contract?

Question

IT Interview Practice · Accepted Answer

**Design by Contract (DbC)** memperlakukan hubungan antara sebuah metode dan pemanggilnya sebagai perjanjian formal, yang ditentukan oleh tiga hal: **prakondisi** (apa yang harus dijamin oleh pemanggil), **postkon-disi** (apa yang dijamin metode sebagai balasannya), dan **invarian** (apa yang tetap benar untuk objek setiap saat).

## Tiga kewajiban

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

## Dalam kode

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

Jika *prakondisi* gagal, **pemanggil** memiliki bug. Jika *postkondisi* atau *invarian* gagal, **metode** memiliki bug — kontrak menunjukkan kesalahan dengan tepat.

## Hubungan dengan LSP

DbC membuat Liskov presisi: subtipe dapat **melemahkan prakondisi** dan **memperkuat postkondisi**, tetapi tidak sebaliknya. Itulah tepat peraturan substitusi, dinyatakan sebagai kontrak.

## Pertukaran

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

## Mengapa ini penting

Kontrak mengubah asumsi yang samar ("jumlah seharusnya positif, saya pikir") menjadi aturan yang eksplisit dan dapat diperiksa — dan mereka menentukan kesalahan dengan tepat ketika sesuatu rusak.

Mereka mendasari substitusi Liskov dan desain API yang kuat: kontrak metode adalah antarmuka sebenarnya, lebih jujur daripada hanya tanda tangannya.

Tiga kewajiban

Dalam kode

Hubungan dengan LSP

Pertukaran

Mengapa ini penting

Soalan berkaitan