接口隔离原则

本文在总结时，大量的依赖了网上博客《设计模式六大原则》中的论述，这篇文章简单易懂，是很不错的。

接口隔离原则：简单来说就是客户端（调用者）不应该依赖它不需要的接口，而只依赖它需要的接口接口，一个类对

另一个类的依赖应该建立在最小的接口之上。换句话说就是接口的定义需要根据客户端的调用来决定，客户端不用的

接口，就不要定义出来了。

接口在我们程序中可以认为它是代表一个角色，不应该将不同的角色合并在一个接口中，这样会导致接口臃肿，也会

导致无效代码的出现，大家可以想象一下，接口中如果有客户端不用的方法被声明出来，那么接口的实现无论如何，

都要去实现出来，这肯定是不优良的设计，记住一句话：“接口的定义，是根据客户的调用决定的”。

举个违背了接口隔离例子：

上述图中，类A和类C作为2个客户端，都依赖于接口I，但是类A中依赖于接口中的方法1,2,3        类C依赖于接口

中的方法1,4,5        但是在接口I的实现类B和类D却5个方法都要实现，尽管C不需要2,3        A不需要4,5

上述的设计导致了类B和D的接口臃肿，而且做了很多不需要的实现，但是没有办法，这个实现类都实现了同一接口

I，而I中定义了1,2,3,4,5这5个不同的方法，可以看的出，如果接口过于臃肿，只要接口中定义的方法，不管对于依赖

于它的类是否有用，接口的实现类中都必须要去实现这些方法，那么如果修改下设计呢？

分析可知，类A中依赖于接口中的1,2,3三个方法，类C中依赖于接口中1,4,5三个方法，那么这两个不同的依赖中，1

是公共的接口方法，那么我们可以把1单独抽离为一个接口，2,3组合为第二个接口，4,5组合为第三个接口，就构成了

上述的图例。

这样我们的类A从依赖一个接口，变成了依赖两个接口，分别是接口I与接口II，JAVA中也是支持单继承多接口的，每

一个接口都成了一个单独的角色，接口II成了一个公共角色。

总体来说：

建立单一接口，不要建立过于臃肿的接口，尽量细化接口，接口中的方法尽量少。我们要为各个类建立专用的接

口，而不是去建立一个很庞大的接口供所有依赖它的类去调用。上述图例中，将一个庞大的接口变更为3个专用的接

口所采用的就是接口隔离原则。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时

对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

例外，需要记住的是接口隔离说的是接口的依赖隔离 ，而单一原则说的是类的职责（功能）需要单一，这两者不是相

同的概念。

使用接口隔离原则时，需要记住的是：

1、接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是事实，但是如果过小，则会造成接

口数量过多，使设计复杂化。所以一定要适度。

2、为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一

个模块提供定制服务，才能建立最小的依赖关系，这条最好的办法就是按照客户端的需要来设计接口，而不是自己设

想。

3、提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。