接口隔离原则

 接口分为两种：

 实例接口：

   在java中声明一个类，然后用new关键字产生一个实例，压实对一个类型的事物的描述，这是一种接口，从某些角度来看，java中的类也是一种接口。

类接口：

java中经常使用的interface关键字定义的接口。

那 什么是接口隔离呢？

1 客户端不应该依赖它不需要的接口

2 类间的依赖关系应该建立在最小的接口上

剖析一下：

 客户端不应该依赖它不许要的接口，那么它依赖什么接口，当然是依赖它需要的接口，客户端需要什么接口你就提供什么接口，

再看第二种定义：

类间的依赖关系应该建立在最小的接口上，它要求是最小的接口，也是要求接口细化，接口纯洁。

通俗一点，接口尽量细化，同时接口中的方法尽量少。

看到这些 大家可能疑惑了？这不和单一职责不是相同的么 ？错，接口隔离原则与单一职责的审视角度不同，单一职责要求是类和接口的职责单一，注意是职责，这是业务上的划分，而接口隔离原则要求接口的方法尽量少。

思考一下这个接口有没有问题呢？是有的，还可以做好更好的优化。

人的审美是会变得。

分析可以发现，接口设计有缺陷，过于庞大，容纳了一些可变的因素。

下面将接口拆分：

接口一定要高内聚：

什么是高内聚？高内聚就是提高接口，类，模块的处理能力。减少对外的交互。具体到接口隔离原则就是尽量少公布public方法。接口是对外的承诺，承认越少对系统的开发越有利，变更的风险也就也就越少，同时也有利于降低成本。

接口的设计粒度越小，系统的灵活性越大，这是不争的实事。

最佳实战：

接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分呢，：

1  一个借口只服务于一个子模块或业务逻辑；

2  通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口打到 “”满身金骨肉“ 而不是肥嘟嘟的。

3  已经被污染的接口，尽量去修改，若变更的风险大，才用适配器的模式进行转化处理。

最后还是那句话 模式是死的人是活的