接口隔离原则：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

接口隔离原则的定义可以翻译为：一个类所包含的应该就是他需要包含的。
如我们定义了一个Person类，他具有人都有的行为：speak()。

此时因为考虑到有的人会拳击，为了让这个类更加“丰富”。于是新增了一个box()接口。

• 首先box并不属于人这个共性抽象类的职责
• 其次一旦新增了box()接口，意味着依赖Person的类变多。如现在有十个类，其中五个需要调用speak()接口，五个需要调用box()接口，在原来的设计中，只有五个类依赖于Person类，由于新增了box接口，这个数量增加到了十个。同时也就意味着，Person类的变动影响的范围变大。

回过头我们来看定义：
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
这个就相对好理解了，本来我调用Person类只能访问到speak方法，新增box接口后意味着我对box方法也有了访问权限。

很多地方将单一职责和接口隔离原则认为是相似的原则，我觉得如果要区分的话可以从如下角度去区分。
单一职责是对接口隔离的进一步划分，他将可以独立变化的职责区分开。单一职责在架构设计中更常用，接口隔离在日常开发中更常用。

先说接口隔离到单一职责的过程

假设系统中有任务模块和会议模块。各自都有增删改查功能。会议中可能要发布任务对任务进行一些操作。

按照接口隔离原则，应该将任务类和会议类区分开。
为什么之前说接口隔离日常用的多呢，因为在日常开发中经常为了图省事自己在某个类中定义一个字符串处理接口或者日期处理接口，方便自己开发过程中复用，但是这些都是不应该对外public的接口

下面进一步就是利用单一职责的进行进一步细分。
现在任务模块包含了四个功能，但是这个类同时也包含了任务的实体类，控制器部分，业务部分和持久化部分，大家看到这里就很明白了，虽然都是对任务的操作都属于任务处理的范围，但是我们会按照上述四个维度将他分为四个类。如果真的都拧在一个类里，显然会乱了套了。