接口隔离原则(Interface Segregation Principle）

定义：
客户端不应该依赖它不需要的接口
类间的依赖关系应该建立在最小的接口上

补充说明：
实例接口(Object Interface)： 在Java中声明一个类，然后用new关键字产生一个实例，是对一个类型的事物的描述，这就是一种接口。或许我们乍一看会有点懵，怎么和我们原来学习的接口不一样呢，其实我们这样想，我们都知道，在Java中有一个Class类，表示正在运行的类和接口，换句话说每一个正在运行时的类或接口都是Class类的对象，这是一种向上的抽象。接口是一种更为抽象的定义，类是一类相同事物的描述集合，那为什么不可以抽象为一个接口呢？
类接口(Class Interface)： 这就是我们经常使用的用interface定义的接口

接口隔离原则中的接口是一种更为宽泛的概念，不止局限于类接口。

注意：
接口隔离原则和单一职责原则非常类似。单一职责原则要求接口的职责是单一的，而接口隔离原则要求接口尽量细化，它们有异曲同工之妙，都是要让我们的接口功能尽量单一，尽量小。

但是，单一职责原则的着重点是在“职责”，而接口隔离原则只单纯地要求接口最小化。那么，如果已经满足单一职责原则的接口，在当前的需求下还可以继续细化，那么还需要细化吗？答案是不要再细化了。在实践中，接口设计的粒度越小，系统就越灵活，这是事实。但是灵活的同时也带来了系统的复杂化，导致开发难度增加。所以接口并不是越小越好，必须要有一个度。当单一职责原则和接口隔离原则存在矛盾时，以满足单一职责原则为底线。

实现方法：
在具体应用接口隔离原则时，应该根据以下几个规则来衡量：
1、接口尽量小，但是要有限度。
2、一个接口只服务于一个子模块或业务逻辑。
3、为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
4、了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
5、提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

举例说明：

代码举例:

利用接口隔离原则改进:

使用原则：
据接口隔离原则拆分接口时，首先必须满足单一职责原则： 没有哪个设计可以十全十美的考虑到所有的设计原则，有些设计原则之间就可能出现冲突，就如同单一职责原则和接口隔离原则，一个考虑的是接口的职责的单一性，一个考虑的是方法设计的专业性(尽可能的少)，必然是会出现冲突。在出现冲突时，尽量以单一职责为主，当然这也要考虑具体的情况。
提高高内聚： 提高接口，类，模块的处理能力，减少对外的交互。比如你给杀手提交了一个订单，要求他在一周之内杀一个人，一周后杀手完成了任务，这种不讲条件完成任务的表现就是高内聚。具体来说就是：要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险就越小，也有利于降低成本。
定制服务： 单独为一个个体提供优良服务(只提供访问者需要的方法)。
接口设计要有限度： 根据经验判断

总结：
使用多个专门的接口比使用单一的总接口要好。