如何保持API的相容

1，採用良好的設計思路

在設計過程中，如果能按照下面的方式來進行設計，會讓這個API生命更長久

• 面向用例的設計，收集使用者建議，把自己類比成使用者，保證API設計的易用和合理
• 保證後續的需求可以通過擴充的形式完成
• 第一版做盡量少的內容，由於新需求可以通過擴充的形式完成，因此盡量少做事情是抑制API設計錯誤的一個有效方案
• 對外提供清晰的API和文檔規範，避免使用者錯誤的使用API，尤其是避免API（見第一節）靠後層級的API被使用者知曉與誤用

除此之外，下面還列出了一些具體的設計方法：

• 方法優於屬性
• Factory 方法優於建構函式
• 避免過多繼承
• 避免由於最佳化或者複用代碼影響API
• 面向介面編程
• 擴充參數應當是便利的
• 對組件進行合理定位，確定暴露多少介面
• 提供擴充點
  

2，有效API評審

API設計完成以後，需要經過周密的設計評審，評審的重點如下：

• 用例驅動，評審前必須提供完善的使用用例，確保用例的合理性和完備性。
• 一致性，是否與系統中其他模組的介面風格一致，是否與對稱介面的設計一致。
• 簡單明了，API應該簡單好理解，容易學習和使用的API才不容易被誤用，給我們帶來更多的麻煩。
• API儘可能少，如果一個API可以暴露也可以不暴露，那麼就不要暴露他，等到使用者真正有需求的時候再將它成為一個公開介面也不遲。
• 支援持續改進，API是否能夠方便地通過擴充的方式增加功能和最佳化。
  

3，把握API的生命週期

每一個API都是有生命週期的，我們需要讓API的生命週期更長，並且在API的生命週期結束時能讓其平滑的消亡。

• 告訴使用者我們是如何設計的，避免誤用，提供指導，錯誤的使用往往是縮短API壽命的一大殺手
• 提供試用期，API不可能一開始就是穩定，經過試用的API才能有更強的生命力
• 為API分級：內部使用；二次開發使用；開發或試用中；穩定；棄用API。避免API被濫用的同時，我們可以通過調整API的層級，來擴大其影響力，也能更優雅的結束一個API的生命週期。
  
  

4，保持API的逐步改善

過去我們總希望能將現有的不合理的設計完全推翻，然後按照現在美好的思路，重新設計這個API，但是在一段時間以後，又會碰到一樣的狀況，需要再推翻一次。

如果我們沒有有效逐步改善的辦法，依靠推翻現有設計，重新設計API只能讓我們回到起點，然後重現之前的過程。要有一套行之有效持續改善的辦法來在API相容的同時，改善API使之更好。

5，提高API的可測試性

API需要是可測試的，測試不應依賴實現，測試充分的API，尤其是經過了嚴格的相容性整合測試的API，更能保證在升級的過程中不出現相容性問題。

相容性整合測試，是指一組測試案例集合，這組測試案例會站在使用者的立場上使用API。在API升級以後，再檢測這組測試案例是否能完全符合預期的通過測試，儘可能的發現相容性問題。

6，避免極端的意見

在設計API的時候，一定要避免任何極端的意見，尤其是以下幾點：

• 必須漂亮
• API必須被正確地使用（使用者很難理解如何正確的使用API，API的設計者要充分考慮API被誤用的情況：如果一個API可能會被誤用，那麼它一定會被誤用）
• 必須簡單（我們總會面臨複雜的需求，能兩者兼顧的API是更好的API）
• 必須高效能（效能可以通過其他手段最佳化，不應該影響API的設計）
• 必須絕對相容（儘管本文一直提到如何保證相容，但是我們仍然要意識到，一些極少情況下會遇到的不相容是可以容忍的）
  

7，一些具體的實施方案

在一個API不可避免要消亡或者改變的時候，我們應該接受並且面對這個事實，下面列舉了幾種保證相容性的前提下，對API進行調整的辦法：

• 將API標記為棄用，重建立立一個新的API。如果一個API不可避免要被消亡，這是唯一的辦法。
• 為其添加額外的參數或者參數選項來實現功能添加
• 將現有API拆成兩部分，提供一個精簡的核心API，過去的API通過封裝核心API上實現。這通常用於解決使用者需要一個代碼精簡的版本時。
• 在現有的API基礎上進行封裝，提供一個功能更豐富的包或者類

以上這些都是一些理論，或者說是方法論，我們還是應該知道的。