基於接口而非實現編程

基於接口而非實現編程。這個原則非常重要，是一種非常有效的提高代碼質量的手段，在平時的開發中特別經常被用到。

基於接口而非實現編程

“基於接口而非實現編程”這條原則的英文描述是：“Program to an interface, not an implementation”。我們理解這條原則的時候，千萬不要一開始就與具體的編程語言掛鉤，侷限在編程語言的“接口”語法中。它先於很多編程語言而誕生（比如 Java 語言），是一條比較抽象、泛化的設計思想，理解這條原則的關鍵，就是理解其中的“接口”兩個字。從本質上來看，“接口”就是一組“協議”或者“約定”，是功能提供者提供給使用者的一個“功能列表”。“接口”在不同的應用場景下會有不同的解讀，比如服務端與客戶端之間的“接口”，類庫提供的“接口”，甚至是一組通信的協議都可以叫作“接口”。剛剛對“接口”的理解，都比較偏上層、偏抽象，與實際的寫代碼離得有點遠。如果落實到具體的編碼，“基於接口而非實現編程”這條原則中的“接口”，可以理解爲編程語言中的接口或者抽象類。

這條原則能非常有效地提高代碼質量，之所以這麼說，那是因爲，應用這條原則，可以將接口和實現相分離，封裝不穩定的實現，暴露穩定的接口。上游系統面向接口而非實現編程，不依賴不穩定的實現細節，這樣當實現發生變化的時候，上游系統的代碼基本上不需要做改動，以此來降低耦合性，提高擴展性。

在軟件開發中，最大的挑戰之一就是需求的不斷變化，這也是考驗代碼設計好壞的一個標準。越抽象、越頂層、越脫離具體某一實現的設計，越能提高代碼的靈活性，越能應對未來的需求變化。好的代碼設計，不僅能應對當下的需求，而且在將來需求發生變化的時候，仍然能夠在不破壞原有代碼設計的情況下靈活應對。而抽象就是提高代碼擴展性、靈活性、可維護性最有效的手段之一。

需要給每個實現類都定義對應的接口嗎？

在開發的時候，是不是任何代碼都要只依賴接口，完全不依賴實現編程呢？做任何事情都要講求一個“度”，過度使用這條原則，非得給每個類都定義接口，接口滿天飛，也會導致不必要的開發負擔。至於什麼時候，該爲某個類定義接口，實現基於接口的編程，什麼時候不需要定義接口，直接使用實現類編程，做權衡的根本依據，還是要回歸到設計原則誕生的初衷上來。只要搞清楚了這條原則是爲了解決什麼樣的問題而產生的，你就會發現，很多之前模棱兩可的問題，都會變得豁然開朗。

這條原則的設計初衷是，將接口和實現相分離，封裝不穩定的實現，暴露穩定的接口。上游系統面向接口而非實現編程，不依賴不穩定的實現細節，這樣當實現發生變化的時候，上游系統的代碼基本上不需要做改動，以此來降低代碼間的耦合性，提高代碼的擴展性。從這個設計初衷上來看，如果在我們的業務場景中，某個功能只有一種實現方式，未來也不可能被其他實現方式替換，那我們就沒有必要爲其設計接口，也沒有必要基於接口編程，直接使用實現類就可以了。

除此之外，越是不穩定的系統，我們越是要在代碼的擴展性、維護性上下功夫。相反，如果某個系統特別穩定，在開發完之後，基本上不需要做維護，那我們就沒有必要爲其擴展性，投入不必要的開發時間。