定义
客户端不应该依赖它不需要的接口；
一个类对另一个类的依赖应该建立在最小的接口上。
定义解读
定义包含三层含义：
- 一个类对另一个类的依赖应该建立在最小的接口上；
- 一个接口代表一个角色，不应该将不同的角色都交给一个接口，因为这样可能会形成一个臃肿的大接口；
- 不应该强迫客户依赖它们从来不用的方法。
接口隔离原则有点像单一职责原则，但是也有区别，在单一职责原则中，一个接口可能有多个方法，提供给多种不同的调用者所调用，但是它们始终完成同一种功能，因此它们符合单一职责原则，却不符合接口隔离原则，因为这个接口存在着多种角色，因此可以拆分成更多的子接口，以供不同的调用者所调用。比如说，项目中我们通常有一个 Web 服务管理的类，接口定义中，我们可能会将所有模块的数据调用方法都在接口中进行定义，因为它们都完成的是同一种功能：和服务器进行数据交互；但是对于具体的业务功能模块来说，其他模块的数据调用方法它们从来不会使用，因此不符合接口隔离原则。
优点
使用接口隔离原则，意在设计一个短而小的接口和类，符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。
问题提出
类 A 通过接口 I 依赖类 B，类 C 通过接口 I 依赖类 D，如果接口 I 对于类 A 和类 C 来说不是最小接口，而类 B 和类 D 必须去实现它们不需要的方法。下面通过一个 UML 图来说明这种现象：
在这里，我们定义了一个动物活动的接口 IAnimal，里面有4个方法：飞行 fly、行走 walk、吃 eat 和工作 work，然后分别用人类 People 和鸟类 Bird 实现了这个接口。中国人类 ChinesePeople 和鹦鹉类 Parrot 通过接口 IAnimal 分别依赖类 People 和类 Bird。很明显，对于 ChinesePeople 来说，fly 方法是多余的，因为人不会飞；对于 Parrot 类来说，work 方法是多余的，因为鹦鹉不需要工作。接口 IAnimal 对于类 ChinesePeople 和类 Parrot 来说不是最小接口。
解决方案
将臃肿的接口 IAnimal 拆分为独立的几个接口，类 ChinesePeople 和类 Parrot 分别与它们需要的接口建立依赖关系，也就是采用接口隔离原则。修改后的 UML 图如下所示：
示例
说明：从 UML 图可以看到，遵守接口隔离原则，会使代码量增加不少，源码中也是这样；实际上，iOS 在定义协议的时候，可以设置方法为可选实现(@optional)和必须实现(@required，默认值)，我们可以设置 work 方法和 fly 方法为可选实现的方法，这样在类 People 和类 Bird 中，这两个方法可以根据需要来决定是否实现。采用这种方式，功能上实现是没有问题，对于简单的接口来说，也便于维护和管理。但是，当方法随着业务需求的增加而不断增加的话，如果我们不应用接口隔离原则，那么就可能形成一个庞大臃肿的接口，这样的接口的可维护性和重用性是很差的。因此，我们应该尽量细化接口，本篇将一个接口变更为3个专用的接口所采用的就是接口隔离原则。在项目开发中，依赖几个专用的接口要比依赖一个综合的接口更加灵活。通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
虽然接口隔离原则很有意义，但在实际项目中，应该注意度的把握，接口设计的过大或过小都不好，应该根据实际情况多思考再进行设计。
