设计模式六大原则--接口隔离原则(Interface Segregation Principle, ISP)

---

参考书籍：设计模式之禅 --- 秦小波 著

在讲接口隔离原则之前，我们首先要明确一下“接口”这个词的含义
接口分为两种：
①实例接口（Object Interface）
在java中，使用new关键字产生一个新的实例，比如Person sanmao = new Person（）;这里的sanmao要遵守的标准就是Person这个类，Person就是sanmao的一个实例接口。
②类接口（Class Interface）
在java中使用Interface关键字修饰的接口。

两种定义
①Clients should not be forced to depend upon interfaces that they don’t use.
客户端不应该依赖它不需要的接口。
②The dependency of one class to another one should depend on the smallest possible interface.
类间的依赖关系应该建立在最小的接口上。
分析：将接口进行细化，最小化，只依赖客户端需要的接口，不需要的剔除掉。
总结：建立单一的接口，同时接口中的方法要尽量的少

问题：这不跟之前说的单一职责原则相同吗？
其实两者着重点不一样。单一职责原则是一个类只负责一类职责，而接口隔离原则着重是的接口单一细化，数量最小化。前者注重职责，是业务逻辑上的划分，后者注重方法数量。

代码重现

//定义一个车属性接口，有轮子，发动机，汽油方法
public interface ICarBo {
   void wheel();
   void engine();
   void gasoline();
}

//定义一个车行为接口，有跑的方法
public interface ICarBiz {
   void run();
}

//定义一个车的实现类
public class Car implements ICarBo,ICarBiz {
   @Override
   public void engine() {
      System.out.println("跑车发动机");
   }
   
   @Override
   public void gasoline() {
      System.out.println("97号汽油");
   }
   
   @Override
   public void run() {
      System.out.println("汽车跑起来了");
   }
   
   @Override
   public void wheel() {
      System.out.println("装了四个轮子");
   }
}

//定义一个人接口，有开车行为方法
public interface IPerson {
   void Driver();
}

//定义一个人的实现类，实现开车方法
public class Person implements IPerson {
   private ICarBiz carBiz;
   private ICarBo carBo;
   
   public void setCarBiz(ICarBiz carBiz) {
      this.carBiz = carBiz;
   }
   
   public void setCarBo(ICarBo carBo) {
      this.carBo = carBo;
   }
   
   @Override
   public void Driver() {
      System.out.println("我是买了一辆车");
      carBo.engine();
      carBo.gasoline();
      carBo.wheel();
      carBiz.run();
   }
}

//测试类
public class Client {
   public static void main(String[] args) {
      ICarBo carBo = new Car();
      ICarBiz carBiz = new Car();
      IPerson person = new Person();
      ((Person) person).setCarBiz(carBiz);
      ((Person) person).setCarBo(carBo);
      person.Driver();
   }
}
-----------------output--------------------
我是买了一辆车
跑车发动机
97号汽油
装了四个轮子
汽车跑起来了

以上代码中，定义了车的基本属性必须有三个：轮子，发动机，汽油，基本行为：跑
乍一看，按照上述写似乎没什么问题，但是仔细想想，我们是不是将汽车的属性给限定死了。不管以后业务逻辑怎么变化，必须满足有轮子，有发动机，有汽油这三个条件，那如果出现无汽油的汽车比如电力汽车，那代码就无法实现。

分析到这里，我们发现 ICarBo 代码有问题，太过于庞大导致如果出现细分情况，就会无法解决。
解决思路：将原ICarBo接口拆分，汽车绝对有发动机，轮子属性，但是在未来，汽油可能不是必须的，因此拆分情况如下：

//汽车基本属性接口
public interface ICarBo {
   void wheel();
   void engine();
}
//汽车燃料接口
public interface ICarFuel {
    void gasoline();
}

将接口这样细分下去，如果以后出现电力汽车，我们可以将ICarFuel改为其它接口就可以了，这样就保持了接口的稳定。

以上把一个庞大笼统的接口细分为多个独立的接口所依赖的原则就是接口隔离原则。

接口隔离原则的具体要求
接口隔离原则是对接口的规范约束，具体有以下四个要求。
①接口尽量要小
作为接口隔离原则的核心定义，要求设计的接口不能臃肿，但是这个“小”是有限度的，首先不能违反单一职责原则。
②接口高内聚
要求在接口中尽量少公布Public方法，减少对外的交互。
③定制服务
单独的为一个个体提供专门的服务，只提供访问者需要的方法。
④接口设计是有限度的
接口设计越细分，系统越灵活，但是结构越复杂化，所以在系统灵活与结构复杂间要适度。