為什么我們要基于接口而非實現編程？
如何解讀原則中的“接口”二字？
是否需要為每個類定義接口？
針對以上問題，下面我們來一個一個的聊一聊。
在軟件開發領域，遵循“面向接口編程而非面向實現編程”的原則是提升代碼質量的關鍵策略。這一原則強調的是，應當依賴于定義良好的接口，而不是具體的實現邏輯。這樣做的目的是為了提高代碼的靈活性和可維護性，降低因實現變化而導致的修改成本。
為了讓你理解透徹，并真正掌握這條原則如何應用，今天，我會結合一個有關圖片存儲的實戰案例來講解。除此之外，這條原則還很容易被過度應用，比如為每一個實現類都定義對應的接口。針對這類問題，我也會告訴你如何來做權衡，怎樣恰到好處地應用這條原則。“基于接口而非實現編程”這條原則的英文描述是：“Program to an interface, not an implementation”。我們理解這條原則的時候，千萬不要一開始就與具體的編程語言掛鉤，局限在編程語言的“接口”語法中（比如 Java 中的 interface 接口語法）。這條原則最早出現于 1994 年 GoF 的《設計模式》這本書，它先于很多編程語言而誕生（比如 Java 語言），是一條比較抽象、泛化的設計思想。要真正領會這一原則，關鍵在于理解“接口”的含義。從本質上來說，“接口”是一組規范或協議，它定義了功能提供者與使用者之間的交互方式。在不同的應用背景下，“接口”可以有不同的含義，例如服務端與客戶端之間的通信接口、類庫提供的API，或者通信協議等。這些理解更偏向于高層次和抽象層面，與具體的編碼活動有一定的距離。然而，在具體的編碼實踐中，“依托抽象接口而非具體實現進行編程”中的“接口”可以被理解為編程語言中的接口或抽象類。正如我們之前提到的，這一原則能夠有效提升代碼品質，這是因為它實現了接口與實現的分離，將不穩定的實現細節封裝起來，而對外提供穩定的接口。當實現發生變化時，依賴于接口的上層系統代碼基本上不需要做出修改，從而降低了系統的耦合度，增強了系統的可擴展性。實際上，“依托抽象接口而非具體實現進行編程”這一原則也可以表述為“依托抽象而非具體實現進行編程”。后者更能體現這一原則的核心意圖。在軟件開發過程中，需求的不斷變化是一個主要挑戰，也是衡量代碼設計優劣的一個重要標準。越高層次、越抽象、越不依賴于某一具體實現的設計，越能夠提升代碼的適應性和靈活性，以應對未來的需求變化。優秀的代碼設計不僅能夠滿足當前的需求，而且在將來需求發生變化時，也能夠在不破壞現有代碼結構的前提下靈活適應。而抽象是提升代碼的可擴展性、靈活性和可維護性的有效手段之一。為了將這一原則應用到實際場景中，我們可以通過一個具體的案例來進行說明。假設在我們的系統中，有大量的圖片處理和存儲業務邏輯。處理后的圖片被上傳至阿里云。為了代碼的復用性，我們封裝了圖片存儲相關的邏輯，并創建了一個統一的AliyunImageStore類供整個系統使用。具體的代碼實現如下：public class AliyunImageStore { // ...省略屬性、構造函數等... public void createBucketIfNotExisting(String bucketName) { // ...創建存儲桶的代碼邏輯... // ...失敗時拋出異常... } public String generateAccessToken() { // ...生成訪問令牌... } public String uploadToAliyun(Image image, String bucketName, String accessToken) { // ...上傳圖片至阿里云... // ...返回圖片在阿里云上的地址(url)... } public Image downloadFromAliyun(String url, String accessToken) { // ...從阿里云下載圖片... }}// AliyunImageStore類的使用示例public class ImageProcessingJob { private static final String BUCKET_NAME = "ai_images_bucket"; // ...省略其他無關代碼... public void process() { Image image = ...; // 處理圖片，并封裝為Image對象 AliyunImageStore imageStore = new AliyunImageStore(/* 省略參數 */); imageStore.createBucketIfNotExisting(BUCKET_NAME); String accessToken = imageStore.generateAccessToken(); imagestore.uploadToAliyun(image, BUCKET_NAME, accessToken); }}
整個上傳流程包括三個步驟：創建存儲桶（可以理解為一個存儲目錄）、生成訪問令牌、攜帶訪問令牌上傳圖片至指定的存儲桶中。代碼實現簡潔明了，類中的方法定義清晰，使用起來也很方便，看起來似乎沒有問題，完全符合我們將圖片存儲在阿里云的業務需求。然而，在軟件開發的世界里，唯一不變的就是變化本身。隨著時間的推移，我們可能會建立自己的私有云，不再使用阿里云存儲圖片，而是將圖片存儲在自己的私有云上。面對這樣的需求變化，我們應該如何調整代碼呢？我們需要重新設計實現一個存儲圖片到私有云的 PrivateImageStore 類，并用它替換掉項目中所有的 AliyunImageStore 類對象。這樣的修改聽起來并不復雜，只是簡單替換而已，對整個代碼的改動并不大。不過，我們經常說，“細節中的魔鬼”。這句話在軟件開發中特別適用。實際上，剛剛的設計實現方式，就隱藏了很多容易出問題的“魔鬼細節”，我們一塊來看看都有哪些。新的 PrivateImageStore 類需要設計實現哪些方法，才能在盡量最小化代碼修改的情況下，替換掉 AliyunImageStore 類呢？這就要求我們必須將 AliyunImageStore 類中所定義的所有 public 方法，在 PrivateImageStore 類中都逐一定義并重新實現一遍。首先，AliyunImageStore 類中有些函數命名暴露了實現細節怎么辦？。
比如，uploadToAliyun() 和 downloadFromAliyun()。如果開發這個功能的同事沒有接口意識、抽象思維，那這種暴露實現細節的命名方式就不足為奇了，畢竟最初我們只考慮將圖片存儲在阿里云上。而我們把這種包含“aliyun”字眼的方法，照抄到 PrivateImageStore 類中，顯然是不合適的。如果我們在新類中重新命名 uploadToAliyun()、downloadFromAliyun() 這些方法，那就意味著，我們要修改項目中所有使用到這兩個方法的代碼，代碼修改量可能就會很大。
其次，將圖片存儲到阿里云的流程，跟存儲到私有云的流程，可能并不是完全一致的怎么辦？
比如，阿里云的圖片上傳和下載的過程中，需要生產 access token，而私有云不需要 access token。一方面，AliyunImageStore 中定義的 generateAccessToken() 方法不能照抄到 PrivateImageStore 中；另一方面，我們在使用 AliyunImageStore 上傳、下載圖片的時候，代碼中用到了 generateAccessToken() 方法，如果要改為私有云的上傳下載流程，這些代碼都需要做調整。那這兩個問題該如何解決呢？解決這個問題的根本方法就是，在編寫代碼的時候，要遵從“基于接口而非實現編程”的原則，具體來講，我們需要做到下面這 3 點。
- 函數的命名不能暴露任何實現細節。比如，前面提到的 uploadToAliyun() 就不符合要求，應該改為去掉 aliyun 這樣的字眼，改為更加抽象的命名方式，比如：upload()。
- 封裝具體的實現細節。比如，跟阿里云相關的特殊上傳（或下載）流程不應該暴露給調用者。我們對上傳（或下載）流程進行封裝，對外提供一個包裹所有上傳（或下載）細節的方法，給調用者使用。
- 為實現類定義抽象的接口。具體的實現類都依賴統一的接口定義，遵從一致的上傳功能協議。使用者依賴接口，而不是具體的實現類來編程。
public interface ImageStore { String upload(Image image, String bucketName); Image download(String url);}public class AliyunImageStore implements ImageStore { // ...省略屬性、構造函數等... public String upload(Image image, String bucketName) { createBucketIfNotExisting(bucketName); String accessToken = generateAccessToken(); // ...上傳圖片至阿里云... // ...返回圖片在阿里云上的地址(url)... } public Image download(String url) { String accessToken = generateAccessToken(); // ...從阿里云下載圖片... } private void createBucketIfNotExisting(String bucketName) { // ...創建存儲桶... // ...失敗時拋出異常... } private String generateAccessToken() { // ...生成訪問令牌... }}// 上傳下載流程變化：私有云不需要訪問令牌public class PrivateImageStore implements ImageStore { public String upload(Image image, String bucketName) { createBucketIfNotExisting(bucketName); // ...上傳圖片至私有云... // ...返回圖片的url... } public Image download(String url) { // ...從私有云下載圖片... } private void createBucketIfNotExisting(String bucketName) { // ...創建存儲桶... // ...失敗時拋出異常... }}// ImageStore的使用示例public class ImageProcessingJob { private static final String BUCKET_NAME = "ai_images_bucket"; // ...省略其他無關代碼... public void process() { Image image = ...; // 處理圖片，并封裝為Image對象 ImageStore imageStore = new PrivateImageStore(...); imagestore.upload(image, BUCKET_NAME); }}
除此之外，很多人在定義接口的時候，希望通過實現類來反推接口的定義。先把實現類寫好，然后看實現類中有哪些方法，照抄到接口定義中。如果按照這種思考方式，就有可能導致接口定義不夠抽象，依賴具體的實現。這樣的接口設計就沒有意義了。不過，如果你覺得這種思考方式更加順暢，那也沒問題，只是將實現類的方法搬移到接口定義中的時候，要有選擇性的搬移，不要將跟具體實現相關的方法搬移到接口中，比如 AliyunImageStore 中的 generateAccessToken() 方法。總結一下，我們在做軟件開發的時候，一定要有抽象意識、封裝意識、接口意識。在定義接口的時候，不要暴露任何實現細節。接口的定義只表明做什么，而不是怎么做。而且，在設計接口的時候，我們要多思考一下，這樣的接口設計是否足夠通用，是否能夠做到在替換具體的接口實現的時候，不需要任何接口定義的改動。根據以上內容，你可能會有這樣的疑問：為了滿足這條原則，我是不是需要給每個實現類都定義對應的接口呢？在開發的時候，是不是任何代碼都要只依賴接口，完全不依賴實現編程呢？
- 做任何事情都要講求一個“度”，過度使用這條原則，非得給每個類都定義接口，接口滿天飛，也會導致不必要的開發負擔。至于什么時候，該為某個類定義接口，實現基于接口的編程，什么時候不需要定義接口，直接使用實現類編程，我們做權衡的根本依據，還是要回歸到設計原則誕生的初衷上來。只要搞清楚了這條原則是為了解決什么樣的問題而產生的，你就會發現，很多之前模棱兩可的問題，都會變得豁然開朗。
- 前面我們也提到，這條原則的設計初衷是，將接口和實現相分離，封裝不穩定的實現，暴露穩定的接口。上游系統面向接口而非實現編程，不依賴不穩定的實現細節，這樣當實現發生變化的時候，上游系統的代碼基本上不需要做改動，以此來降低代碼間的耦合性，提高代碼的擴展性。
- 從這個設計初衷上來看，如果在我們的業務場景中，某個功能只有一種實現方式，未來也不可能被其他實現方式替換，那我們就沒有必要為其設計接口，也沒有必要基于接口編程，直接使用實現類就可以了。
- 除此之外，越是不穩定的系統，我們越是要在代碼的擴展性、維護性上下功夫。相反，如果某個系統特別穩定，在開發完之后，基本上不需要做維護，那我們就沒有必要為其擴展性，投入不必要的開發時間。
- “基于接口而非實現編程”，這條原則的另一個表述方式，是“基于抽象而非實現編程”。后者的表述方式其實更能體現這條原則的設計初衷。我們在做軟件開發的時候，一定要有抽象意識、封裝意識、接口意識。越抽象、越頂層、越脫離具體某一實現的設計，越能提高代碼的靈活性、擴展性、可維護性。
- 我們在定義接口的時候，一方面，命名要足夠通用，不能包含跟具體實現相關的字眼；另一方面，與特定實現有關的方法不要定義在接口中。
- “基于接口而非實現編程”這條原則，不僅僅可以指導非常細節的編程開發，還能指導更加上層的架構設計、系統設計等。比如，服務端與客戶端之間的“接口”設計、類庫的“接口”設計。
該文章在 2024/4/19 18:03:39 編輯過
400 186 1886
