【面向对象】开发原则（二）：基于接口而非基于实现编程

迷南。 2023-01-14 01:57 160阅读 0赞

## 1.如何理解该原则？ ##

这条原则能非常有效地提高代码质量，实际上，“基于接口而非实现编程”这条原则的另一个表述方式，是“**基于抽象而非实现编程**”。后者的表述方式其实更能体现这条原则的设计初衷。

在软件开发中，大的挑战之一 就是需求的不断变化，这也是考验代码设计好坏的一个标准。**越抽象、越顶层、越脱离具体某一实现的设计，越能提高代码的灵活性，越能应对未来的需求变化**。好的代码设计，不仅能应对当下的需求，而且在将来需求发生变化的时候，仍然能够在不破坏原有代码设计的情况下灵活应对。而抽象就是提高代码扩展性、灵活性、可维护性有效的手段之一。

应用这条原则，可以将**接口和实现相分离，封装不稳定的实现，暴露稳定的接口。上游系统面向接口而非实现编程，不依赖不稳定的实现细节**，这样当实现发生变化的时候，上游系统的代码基 本上不需要做改动，以此来降低耦合性，提高扩展性。

## 2.如何将这条原则应用到实战中？ ##

我们下面来看个例子。

假设我们的系统中有很多涉及图片处理和存储的业务逻辑。图片经过处理之后被上传到阿里云上。为了代码复用，我们封装了图片存储相关的代码逻辑，提供了一个统一的 AliyunImageStore 类，供整个系统来使用。

// 定义阿里云上传实体类
    public class AliyunImageStore {
          
        //... 省略属性、构造函数等...    
        public void createBucketIfNotExisting(String bucketName) {
          
            // ... 创建 bucket 代码逻辑...   
            // ... 失败会抛出异常..  
        }  
        
        public String generateAccessToken() {
            
            // ... 根据 accesskey/secrectkey 等生成 access token 
        }   
        public String uploadToAliyun(Image image, String bucketName, String accessTok  
           //... 上传图片到阿里云...  
           //... 返回图片存储在阿里云上的地址 (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); 
         }  
     }

### 2.1 出现问题：**需求变更** ###

若现在需求是上传到私有云，该如何实现？

我们需要重新设计实现一个存储图片到私有云的 PrivateImageStore 类，并用它替换掉项目中所有的 AliyunImageStore 类对象。这样的修改听起来并不复杂，只是简单替换而 已，对整个代码的改动并不大。

不过，我们经常说，“细节是魔鬼”。这句话在软件开发中特别适用。实际上，刚刚的设计实现方式，就隐藏了很多容易出问题的“魔鬼细节”，我们一块来看看都有哪些。

新的 PrivateImageStore 类需要设计实现哪些方法，才能在尽量小化代码修改的情况下，替换掉 AliyunImageStore 类呢？这就要求我们**必须将 AliyunImageStore 类中所定义的所有 public 方法，在 PrivateImageStore 类中都逐一定义并重新实现一遍**。而这样做就会存在一些问题，比如：

1）首先，**AliyunImageStore 类中有些函数命名暴露了实现细节**，比如，uploadToAliyun() 和downloadFromAliyun()。如果开发这个功能的同事没有接口意识、抽象思维，那这种暴露实现细节的命名方式就不足为奇了，毕竟最初我们只考虑将图片存储在阿里云上。而我们把这种包含“aliyun”字眼的方法，照抄到 PrivateImageStore 类中，显然是不合适的。

如果我们在新类中重新命名 uploadToAliyun()、downloadFromAliyun() 这些方法， 那就意味着，我们要修改项目中所有使用到这两个方法的代码，代码修改量可能就会很大。

2）其次，**将图片存储到阿里云的流程，跟存储到私有云的流程，可能并不是完全一致的**。比如，阿里云的图片上传和下载的过程中，需要生产 access token，而私有云不需要 access token。

一方面，AliyunImageStore 中定义的 generateAccessToken() 方法不能照抄到 PrivateImageStore 中；

另一方面，我们在使用 AliyunImageStore 上传、下载图片的时候，代码中用到了 generateAccessToken() 方法，如果要改为私有云的上传下载流程，这些代码都需要做调整。

### 2.2 问题解决：依赖接口设计 ###

解决这个问题的根本方法就是，在编写代码的时候，要遵从“基于接口而非实现编程”的原则

*  **接口函数的命名不能暴露任何实现细节**。比如，前面提到的 uploadToAliyun() 就不符合要 求，应该改为去掉 aliyun 这样的字眼，改为更加抽象的命名方式，比如：upload()。
 *  **实现类中封装具体的实现细节**。比如，跟阿里云相关的特殊上传（或下载）流程不应该暴露给调用者。我们对上传（或下载）流程进行封装，对外提供一个包裹所有上传（或下载）细节的方法，给调用者使用
 *  **为实现类定义抽象的接口。具体的实现类都依赖统一的接口定义**，遵从一致的上传功能协议。使用者依赖接口，而不是具体的实现类来编程。

**–> 如果要变更实现，只换实现类那一处就OK，其余调用都不用改变**

我们按照这个思路，把代码重构一下。重构后的代码如下所示：

public interface ImageStore {
          
        String upload(Image image, String bucketName);  
        Image download(String url); 
        // 与实现类具体相关的方法补定义，如生成token
    }
    
    // 上传到阿里云
    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);  
        } 
    }

## 3.是否需要为每个类定义接口？ ##

为了满足这条原则，我是不是需要给每个实现类都定义对应的接口呢？在开发的时候，是不是任何代码都要只依赖接口，完全不依赖实现编程呢？

这条原则的设计初衷是，**将接口和实现相分离，封装不稳定的实现，暴露稳定的接口。上游系统面向接口而非实现编程，不依赖不稳定的实现细节**，这样当实现发生变化的时候，上游系统的代码基本上不需要做改动，以此来降低代码间的耦合性，提高代码的扩展性

*  从这个设计初衷上来看，如果在我们的业务场景中，**某个功能只有一种实现方式，未来也不可能被其他实现方式替换**，那我们就没有必要为其设计接口，也没有必要基于接口编程，直接使用实现类就可以了。
 *  除此之外，越是不稳定的系统，我们越是要在代码的扩展性、维护性上下功夫。相反，**如果某个系统特别稳定，在开发完之后，基本上不需要做维护**，那我们就没有必要为其扩展性， 投入不必要的开发时间。