《代码整洁之道》的作者Robert C.Martin于2002年给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法
该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上
通常我们一个类，可能会需要实现很多方法，如果将这么多的方法都抽象在同一个接口上，那么就会产生强依赖，不利于扩展。因为别人也会想要用这个接口，但是你在接口中定义了那么多的方法，我只要想实现你的接口，就必须实现你所有的方法
接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
简单一点理解就是：把一个庞大的接口根据业务场景拆分成几个小的接口。
接口隔离是为了高内聚、低耦合。在实际的业务开发中，通常会先定义好需要开发的接口，并由各个服务类实现。但如果没有经过考虑和设计，就很可能造成一个接口中包括众多的接口方法，而这些接口并不一定在每一个类中都需要实现。这样的接口很难维护，也不易于扩展，每一次修改验证都有潜在的风险。
我们开发中常遇见的胖接口，就是因为不遵循接口隔离原则导致的，一个接口包含大量的接口方法，实现类需要实现所有方法，但实现类又不一定需要这些方法。
如下UML图：
ISP (2).jpg
按接口隔离原则拆分：
ISP (3).jpg
在具体应用接口隔离原则时，应该根据以下几个规则衡量。
·接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
·为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
·了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同，要深入了解业务逻辑。
·提高内聚，减少对外交互。让接口用最少的方法完成最多的事情。
