# Design by Contract (DbC)

依合約設計（Design by Contract, DbC）是一種設計方法，預期輸入、輸出和副作用皆備有文件記錄下來。合約描述期望程式碼的運作方式以及呼叫者期望得到的回應，這就是合約設計。

---
## 開發與合約細節
DbC 通常由雙方協議與開發，若合約被違反，則會拋出異常處理來說明無法運行的原因。

設計者要經常問：

- 它期望的是什麼？
- 它要保證的是什麼？
- 它要保持的是什麼？

以下均為合約的一部分:
- 可接受和不可接受的值或類型，以及它們的含義
- 返回的值或類型，以及它們的含義
- 可能出現的錯誤以及異常情況的值和類型，以及它們的含義
- 前置條件：呼叫函數前必須完成的條件
- 例如：使用日幣與台幣匯率轉換函式前，貨幣需要是整數，且輸入的貨幣不能為負數（對呼叫者施加限制）
> 前置條件若未滿足，則程式不應執行

- **後置條件**：呼叫者呼叫函數所期望的結果，並進行驗證
- 例如：日幣轉換成台幣時，函式會做匯率轉換，並驗證台幣幣值是否大於日幣（事後驗證）。驗證通過後回傳匯率結果

- **不變量**：程式執行多少次都不會變動的事物
- 例如：換匯手續費永遠不變，就是 0.00125%，為券商手續費（永遠不變）

- **副作用**：程式碼中的副作用
- 在執行換匯函式時，還會更新目前外幣帳戶的存款（除了返回值外，還對主調用函數產生附加的影響）

對於邏輯驗證，有兩種主要方法可以討論：在呼叫函數前進行驗證，或直接將驗證責任交給函數本身。前者被歸類為「寬容作法」，後者則是「嚴格作法」。在這兩種方法中，「寬容作法」指的是在呼叫函數之前對函數的輸入進行驗證；而「嚴格作法」則是指將驗證責任完全交給函數本身。業界常見使用嚴格作法，因為從強健性角度來看，它是最安全的。

## DbC 主要價值：

- 發生錯誤時，可以專注於前置條件或後置條件，加快查找錯誤原因
- 在前後端分離時，職責較明確，避免重複邏輯，遵循非冗餘原則
- 更能掌控系統，只需查看合約即可了解全貌
- 單元測試更容易聚焦有意義的商業邏輯，減少無價值的測試