设计模式学习笔记——接口隔离原则

定义：

1、客户端不应该依赖于它不需要的接口

2、类间的依赖关系应该建立在最小的接口上

通俗的讲，应该建立单一的接口，不要建立臃肿庞大的接口，即接口应该尽量细化，同时接口中的方法尽量少。

举例：

要成为一名美女必须具备三个条件：面貌、身材、气质，星探找美女的过程如下类图所示：

IPrettyGirl接口中定义了三个方法，只有这三个条件都满足，才会被称作美女，在星探的抽象类中，用show()方法分别输出美女的三个条件。这样的设计对现在来说已经非常的好了，美女嘛，就应该具备这三个条件，但是我们是为了说明接口的隔离原则，假如情况发生了一下改变，随着时间的推移，我们的审美观发生了变化，美女呢，又分为两种，一种是气质型美女，一种是外表型美女，这两种美女都叫做美女，气质型美女只要具备greateTemperament()的特征就叫做美女，而外表型美女只要具备goodLooking()和niceFigure()就可以了。但是我们现有的设计却是将这三个特征合在一起才叫做美女，多少有些死板，不太灵活，而且不能很好的表达我们的审美观，也给星探对美女的划分带来一些疑惑，那么我们应该怎么做呢？嘿嘿，这就是接口隔离原则的用武之地了，来看改进之后的类图：

改进之后的类图将一个接口拆成了两个接口，对接口又进行了细化，这样我们既可以识别气质型美女，又可以识别外表型美女，而且还可以两者兼有，不错吧，比较灵活了吧？

接口是我们设计时，对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。但是应用接口隔离原则时，也是有一些原则的：

1、接口要尽量小，不出现臃肿的接口，但是“小”是有限度的，小到什么程度呢？就是小到不能违背单一职责原则。

2、接口要高内聚，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少，对系统的开发越有利，变更的风险也就越少，同时有利于降低成本。

3、通过接口来定制服务，即模块之间必然存在耦合，定制服务即只提供访问者需要的方法。

忠告：

接口不能太大也不能太小，接口粒度太小，会导致接口的数量剧增，接口粒度太大，灵活性降低，无法提供定制服务，应该根据经验和常识决定接口的粒度大小。

补充：接口隔离原则和单一职责原则的区别

两者的很相似，但是两者的审视角度是不同的，单一职责原则要求是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求的是接口的方法尽量少。例如，一个接口中有很多方法，提供给很多模块去访问，按照单一职责原则这是允许的，因为这一个接口实现的是一个单一的职责，这个职责可以被很多模块来使用，但是却违背了接口隔离原则，因为接口隔离原则要求一个接口只服务于一个子模块或业务逻辑，这两者间怎么去取舍，就要看实际的情况了。