## 面向介面程式設計原理 “基於介面而非實現程式設計”這條原則的英文描述是:“Program to an interface, not an implementation”。我們理解這條原則的時候,千萬不要一開始就與具體的程式語言掛鉤,侷限在程式語言的“介面”語法中(比如 Java 中的 interface 介面語法)。這條原則最早出現於 1994 年 GoF 的《設計模式》這本書,它先於很多程式語言而誕生(比如 Java 語言),是一條比較抽象、泛化的設計思想。 這條原則能非常有效地提高程式碼質量,之所以這麼說,那是因為,應用這條原則,可以:: - **將介面和實現相分離** - **封裝不穩定的實現** - **暴露穩定的介面** 上游系統面向介面而非實現程式設計,不依賴不穩定的實現細節,這樣當實現發生變化的時候,上游系統的程式碼基本上不需要做改動,以此來**降低耦合性,提高擴充套件性**。 實際上,“基於介面而非實現程式設計”這條原則的另一個表述方式,是“基於抽象而非實現程式設計”。後者的表述方式其實更能體現這條原則的設計初衷。在軟體開發中,最大的挑戰之一就是需求的不斷變化,這也是考驗程式碼設計好壞的一個標準。越抽象、越頂層、越脫離具體某一實現的設計,越能提高程式碼的靈活性,越能應對未來的需求變化。好的程式碼設計,不僅能應對當下的需求,而且在將來需求發生變化的時候,仍然能夠在不破壞原有程式碼設計的情況下靈活應對。**而抽象就是提高程式碼擴充套件性、靈活性、可維護性最有效的手段之一**。 ## 面向介面程式設計實踐 假設我們的系統中有很多涉及圖片處理和儲存的業務邏輯。圖片經過處理之後被上傳到阿里雲上。為了程式碼複用,我們封裝了圖片儲存相關的程式碼邏輯,提供了一個統一的 AliyunImageStore 類,供整個系統來使用。具體的程式碼實現如下所示: ```java public class AliyunImageStore { //...省略屬性、建構函式等... public void createBucketIfNotExisting(String bucketName) { // ...建立bucket程式碼邏輯... // ...失敗會丟擲異常.. } public String generateAccessToken() { // ...根據accesskey/secrectkey等生成access token } 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); } } ``` 整個上傳流程包含三個步驟:建立 bucket(你可以簡單理解為儲存目錄)、生成 access token 訪問憑證、攜帶 access token 上傳圖片到指定的 bucket 中。程式碼實現非常簡單,類中的幾個方法定義得都很乾淨,用起來也很清晰,乍看起來沒有太大問題,完全能滿足我們將圖片儲存在阿里雲的業務需求。 不過,軟體開發中唯一不變的就是變化。過了一段時間後,我們自建了私有云,不再將圖片儲存到阿里雲了,而是將圖片儲存到自建私有云上。為了滿足這樣一個需求的變化,我們該如何修改程式碼呢? 我們需要重新設計實現一個儲存圖片到私有云的 PrivateImageStore 類,並用它替換掉專案中所有的 AliyunImageStore 類物件。這樣的修改聽起來並不複雜,只是簡單替換而已,對整個程式碼的改動並不大。不過,我們經常說,“細節是魔鬼”。這句話在軟體開發中特別適用。實際上,剛剛的設計實現方式,就隱藏了很多容易出問題的“魔鬼細節”,我們一塊來看看都有哪些。 新的 PrivateImageStore 類需要設計實現哪些方法,才能在儘量最小化程式碼修改的情況下,替換掉 AliyunImageStore 類呢?這就要求我們必須將 AliyunImageStore 類中所定義的所有 public 方法,在 PrivateImageStore 類中都逐一定義並重新實現一遍。而這樣做就會存在一些問題,我總結了下面兩點。 首先,AliyunImageStore 類中有些函式命名暴露了實現細節,比如,uploadToAliyun() 和 downloadFromAliyun()。如果開發這個功能的同事沒有介面意識、抽象思維,那這種暴露實現細節的命名方式就不足為奇了,畢竟最初我們只考慮將圖片儲存在阿里雲上。而我們把這種包含“aliyun”字眼的方法,照抄到 PrivateImageStore 類中,顯然是不合適的。如果我們在新類中重新命名 uploadToAliyun()、downloadFromAliyun() 這些方法,那就意味著,我們要修改專案中所有使用到這兩個方法的程式碼,程式碼修改量可能就會很大。 其次,將圖片儲存到阿里雲的流程,跟儲存到私有云的流程,可能並不是完全一致的。比如,阿里雲的圖片上傳和下載的過程中,需要生產 access token,而私有云不需要 access token。一方面,AliyunImageStore 中定義的 generateAccessToken() 方法不能照抄到 PrivateImageStore 中;另一方面,我們在使用 AliyunImageStore 上傳、下載圖片的時候,程式碼中用到了 generateAccessToken() 方法,如果要改為私有云的上傳下載流程,這些程式碼都需要做調整。 那這兩個問題該如何解決呢?解決這個問題的根本方法就是,在編寫程式碼的時候,要遵從“基於介面而非實現程式設計”的原則,具體來講,我們需要做到下面這 3 點。 1. 函式的命名不能暴露任何實現細節。比如,前面提到的 uploadToAliyun() 就不符合要求,應該改為去掉 aliyun 這樣的字眼,改為更加抽象的命名方式,比如:upload()。 1. 封裝具體的實現細節。比如,跟阿里雲相關的特殊上傳(或下載)流程不應該暴露給呼叫者。我們對上傳(或下載)流程進行封裝,對外提供一個包裹所有上傳(或下載)細節的方法,給呼叫者使用。 1. 為實現類定義抽象的介面。具體的實現類都依賴統一的介面定義,遵從一致的上傳功能協議。使用者依賴介面,而不是具體的實現類來程式設計。 我們按照這個思路,把程式碼重構一下。重構後的程式碼如下所示: ```java 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) { // ...建立bucket... // ...失敗會丟擲異常.. } private String generateAccessToken() { // ...根據accesskey/secrectkey等生成access token } } // 上傳下載流程改變:私有云不需要支援access token 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) { // ...建立bucket... // ...失敗會丟擲異常.. } } // 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() 方法。 總結一下,我們在做軟體開發的時候,一定要有抽象意識、封裝意識、介面意識。**在定義介面的時候,不要暴露任何實現細節。介面的定義只表明做什麼,而不是怎麼做**。而且,在設計介面的時候,我們要多思考一下,這樣的介面設計是否足夠通用,是否能夠做到在替換具體的介面實現的時候,不需要任何介面定義的改動。 ## 面向介面程式設計總結 1. “基於介面而非實現程式設計”,這條原則的另一個表述方式,是“基於抽象而非實現程式設計”。後者的表述方式其實更能體現這條原則的設計初衷。我們在做軟體開發的時候,一定要有抽象意識、封裝意識、介面意識。越抽象、越頂層、越脫離具體某一實現的設計,越能提高程式碼的靈活性、擴充套件性、可維護性。 1. 我們在定義介面的時候,一方面,命名要足夠通用,不能包含跟具體實現相關的字眼;另一方面,與特定實現有關的方法不要定義在介面中。 1. “基於介面而非實現程式設計”這條原則,不僅僅可以指導非常細節的程式設計開發,還能指導更加上層的架構設計、系統設計等。比如,服務端與客戶端之間的“介面”設計、類庫的“介面”