Michael Feathers

API 設計的困難#

API 設計是困難的，尤其是大型 API。如果你正在設計一個會有數百或數千個使用者的 API，你必須思考：

• 未來可能如何修改它，以及你的修改是否會破壞客戶端程式碼
• 使用者可能會繼承你的類別並覆寫方法——你未來將無法自由更改那個方法
• 你的內部實作選擇實際上受到使用者的擺佈

鎖定 API 的誘惑#

API 開發者用各種方式解決這個問題，但最簡單的方式是鎖定 API：

• 在 Java 中將類別和方法設為 final
• 在 C# 中將類別和方法設為 sealed
• 使用 singleton 或 static factory 方法來限制存取

這一切看似合理，但真的是正確的做法嗎？

單元測試揭示的問題#

過去十年，業界逐漸認識到單元測試（unit testing）是非常重要的實踐。試著拿一個使用第三方 API 的任意未測試類別，為它撰寫單元測試。大多數時候你會發現：使用該 API 的程式碼像膠水一樣黏住了，無法模擬 API 類別的互動或提供測試用的回傳值。

API 設計的黃金法則#

API 設計的黃金法則：光為你開發的 API 撰寫測試是不夠的，你還必須為使用你 API 的程式碼撰寫單元測試。

當你遵循這條規則時，你會親身體驗使用者在嘗試獨立測試他們的程式碼時必須克服的障礙。

實務建議#

static、final、sealed 本身並不是壞的構造——有時候確實有用。但重要的是意識到測試性（testability）的議題，並且親身體驗它。一旦你這樣做了，你就能像面對任何其他設計挑戰一樣來處理它。