接口隔离原则（Interface Segregation Principle）讲的是：使用多个专门的接口比使用单一的接口总要好。换言之从一个客户类的角度来讲：
一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它不用的方法。
接口隔离原则的定义如下：
客户端不应该依赖那些它不需要的接口。
另一种定义方法如下：
一旦接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需要知道与之相关的方法即可。
接口隔离原则是指使用多个专门的接口（抽象类也是接口），而不是使用单一的总接口。每个接口应该承担一种相对独立的角色，不多不少，不干不该干的事，该干的事情都要干。
（1）一个接口只代表一个角色，每个角色都有它特定的一个接口，此时这个原则可以叫做"角色隔离原则"。
（2）接口仅仅提供客户端需要的行为，即所需的方法，客户端不需要的行为则隐藏起来，应当为客户提供尽可能小的单独接口，而不是提供大的总结口。
使用接口隔离原则对接口进行约束时，需要注意以下几点：
接口尽量小，但是要有限度。对接口进行细化可以提高程序设计的灵活性是不争的事实，但是如果过小，则会造成接口数量过多，使设计复杂化，所以一定要适度。
为依赖接口的类定制服务，只暴露给调用的类需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小依赖关系。
提高内聚，减少对外交互。使接口用最少的方法完成最多的事情。
运用接口隔离原则，一定要适度（类中的接口数量要适度），接口设计的过大或过小都不好，设计接口的时候，只有多花时间去思考和筹划
才能准确地实践这一原则。
总结：当客户类被强迫依赖那些它们不需要的接口时，则这些客户类不得不受制于这些接口。这无意间就导致了所有客户类之间的耦合。换句话说，如果一个客户类依赖了一个类，这个类包含了客户类不需要的接口，但这些接口是其他客户类所需要的，那么其他客户类要求修改这个类时，这个修改也将影响这个客户类。通常我们都是尽可能的避免这种耦合，所以我们需要竭尽全力地分离这些接口。
接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说我们要为各个类建立专门的接口，而不是试图建立一个很庞大的接口供所有依赖他的类去调用。在程序设计中依赖几个专用的接口比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
说到这里，很多人觉的接口隔离原则跟之前的单一职责原则很相似其实不然：
其一，单一职责原则注重的是职责，而接口隔离原则注重对接口依赖的隔离。
其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中实现和细节；而接口隔离原则主要约束接口，主要针对抽象，针对程序整体框架的构建。