基于接口而非实现编程---推己及人-CSDN博客

本文链接：https://blog.csdn.net/u014775579/article/details/130357537

前言

上篇我们讲了抽象类和接口，也说了他们的使用场景，这里我们通过实战感受下他们的使用。引出今天的主题：基于接口而非实现编程。这个原则非常重要，是一种非常有效的提高代码质量的手段，在平时的开发中经常被用到。

首先这里的接口不是指Java的Interface，他是一种抽象的概念，比如服务端提供给前端的接口，只是一种协议和约定，包含Java抽象类和接口。面向接口编程远早于Java的面世，所以他是一种普适的编程思想。

一般来说越抽象越能涵盖更多的场景和变化，抽象的最高境界就是“无象”，正因为无象所以能包罗万象。抽象的使用总结就一句话，将接口和实现相分离，封装不稳定的实现，暴露稳定的接口。（将确定性留给别人，将不确定性留给自己）。
看下面的例子：
我们要实现一个文件存储的功能，需要将文件存储到磁盘中，代码实现如下：

public class FileSave {
   public void initDisk(){
     System.out.println("初始化磁盘!");
   }
   public String saveFileToDisk( File file, String name ){
     System.out.println("存储文件到磁盘!");
   }
   public String readFileFromDisk( String name ){
     System.out.println("从磁盘读取文件!");
   }
}

好了，上面的类实现了所需要的功能，咋一看没有问题。但是突然有一天，需求变了，要求所有的文件都要保存在Oss上，这个时候来看这段代码，他的修改会有巨大的工作量和风险，怎么修改呢。

存在的问题
1、修改方法中代码的实现，这个不是问题。
2、需要修改方法名，因为目前这个方法名太过具体，不适用于保存到Oss的场景，所以需要修改。可是工程中有几百上千次的调用，一一改动就有巨大的风险和工作量。
3、这个initDisk方法本来应该对别人无感，但是你暴漏了这个方法，没有做好封装，其他人可能也调用了，这时候也要修改。有了额外的工作量和风险，回归的时候还存在文件内部初始化，外部初始化等多种场景，回归工作量很大。

上面所有问题的根因就是他忽略了抽象，代码具体化到了磁盘，使其失去了扩展性。

如果我们在实现的时候考虑和以后的扩展性，就可以完美解决这个问题。代码如下：

public interface FileSaveI {
   String saveFile( File file, String name );
   String readFile( String name );
}


public class FileSave implements FileSaveI {
  
  public void init(){
    System.out.pintln("初始化");
  }
  public String saveFile( File file, String name ){
    System.out.pintln("保存文件");
  }
  public String readFile( String name ){
    System.out.pintln("读取文件");
  }
}