设计模式6大原则（4）：接口隔离原则

接口隔离原则

接口隔离原则：Interface Segregation Principle（ISP）

       这个原则从字面上就能知道什么意思，隔离开接口，那什么是接口，如何隔离呢？

       首先确定接口定义，这里的接口分为2种：

       1.类接口，比如Java中使用interface声明的接口。

       2.实例接口，也就是创建实例的类，比如Object obj = new Object();这里面obj是实例，Object就是obj的实例接口，obj必须遵从Object。用Java编程久了这点不太好理解，抽象出来看就好了。

了解接口了，我们看看它如何隔离的，接口隔离原则定义有2方面：

       1.Clients should not be forced to depend upon interfaces that they don't use.用户端不应该依赖它不需要的接口。

       2. Thedependency of one class to another one should depend on the smallest possibleinterface.类间的依赖关系应该建立在最小的接口上。

       用户端不应该依赖它不需要的接口，即只依赖它需要的接口。废话，不需要的接口还依赖什么。看着像说了一句废话似的，类间的依赖关系应该建立在最小的接口上，谁会创建大接口呀，看着还是废话。但是往往事实和理想都存在差距，很多人都创建了大量的臃肿接口。

       其实我们看例子

       客户端类A依赖接口0，使用了实现类C，假如他只用到了方法1、方法2、方法3；

       客户端类B依赖接口0，使用了实现类D，假如他只用到了方法2、方法3、方法4、方法5。

       对于客户端类A，他没用到方法4、方法5，客户端类B就没用到方法1。

       这就违反了接口隔离，依赖了它不需要的接口，类间的关系也不是最小的接口，因为这个接口还能细化，比如下面这个：

       这样就好多了，接口被细化了，保证了其纯洁性。

       还一点不应该强迫用户依赖于它们不用的方法。接口属于用户的，不属于它所在的类层次结构。这个说得很明白了，再通俗点说，不要强迫用户使用它们不用的方法，就像上面的例子，类A是使用方法2，3，就不要让我看到方法4，5了，如果强迫用户使用它们不使用的方法，那么这些用户就会面临由于这些不使用的方法的改变所带来的改变。

       如何不强迫，可以使用委派分离接口，使用多重继承分离接口。

       简单理解就是用户用哪个方法，就提供哪个方法，不要额外提供多余的方法。转换到具体实现层面，就是能不用public就不用public。

       接口隔离主要含义就是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。换句话说，我们应该建立多个专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。过于臃肿的接口是对接口的污染，细化、专一的接口才是纯洁的接口。本文例子中，将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

       说到这里，很多人会觉的接口隔离原则跟单一职责原则很相似。其实这两个原则的审视角度不同：单一职责原则原注重的是职责，主要是业务逻辑上的划分，接口隔离原则要求接口方法尽量少，对外暴露少。例如，一个接口就一个职责，但是有10个方法，各个模块按照规定的权限访问，系统外通过文档约束，不使用的方法不要访问，按照单一职责是允许的，按照接口格式是不允许的，因为它要求尽量使用多个专门的接口。

       采用接口隔离原则对接口进行约束时，要注意以下几点：

              1.接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。

              2.为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

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

              4.运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。