編程API和編程到接口

Question

通常建議「編程到接口，而不是實現」。促進關注的分離是有用的，並有助於單元測試。不過，我正在考慮API編程。

假設我編寫了一個API，並且該API使用了大量的「編程接口」。我們還要說，API非常受歡迎，並被許多外部客戶使用。如果API中的某個接口必須更改，那需要重新編譯使用API​​的應用程序。

我的問題是，這樣的問題如何避免（或減少這種變化的影響），還是它是不可避免的？我不是一個API程序員，並希望知道這裏的最佳做法。在我看來，改變已經存在很長時間並被廣泛使用的界面是一個不好的主意。

Answer 1

發佈的接口不應該改變。在必須增加功能的情況下，只需添加一個新界面即可。

從MSDN引用：

當你創建一個界面，你是 創建一個可以永遠接口定義 後 變化已經發布了一個定義。該接口 不變是組件設計的重要原理 ，因爲它 保護已編寫 的現有系統使用該接口。

當一個接口明顯需要增強時，需要創建一個新接口 。此接口可能是 ，通過在原始接口名稱上附加「2」來命名，以顯示其與現有接口 的關係 。

Answer 2

我認爲這裏可以區分API和服務以及API與庫之間的區別。

在服務的情況下，這些API不應該被打破。向這些接口添加接口不會影響現有的消費者。

更改庫API只需要重新編譯，如果消費者想要使用較新版本的庫。這很可能會與重新編譯一起進行，只需添加到接口中就不需要更改現有代碼（如果適用，可以使用屬性標記不推薦使用的方法）。

如果您確實需要對API進行重大更改，那麼是的，消費者將不得不更改其代碼以使其可構建。雖然這不能掉以輕心，但還是有很多非常流行的庫，其API隨着時間的推移發生了顯着變化（流暢的NHibernate出現），並且從我的角度來看，至少，更新我的項目的痛苦是微乎其微的特別是考慮到這些更新帶來的改進。

我認爲，對於圖書館來說，有一種期望，即在採用新版本時可能需要進行一些調整。同樣，有一個預期，如果API在而不是更改，工作代碼不應該被新版本打破。