《设计模式之禅》六大设计原则之四---接口隔离原则

（四） 接口隔离原则

1.     概念：这里的接口包含两类，实例接口（class）和类接口（Interface），通俗一点将即是建立单一接口，不要建立臃肿庞大的接口，更通俗点就是接口尽量的细化，同时接口中的方法尽量少。

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

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

     与单一职责原则的区分在于，单一职责需要要求类和接口的职责单一，注重的是职责，这是业务逻辑的划分，而接口隔离原则要求接口中的方法尽量少。如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且供给多个模块儿访问，各个模块儿按照规定的权限来访问，在系统外通过文档约束“不使用方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求尽量使用“多个专门的接口”，提供给几个模块儿就应该有几个接口，而不是建立一个庞大臃肿的接口，容纳所有客户端的访问。

2. 示例：以一个星探查找美女的类图4-1实现（该关联是否为聚合，有待商榷，书本上是聚合，本人觉得用依赖关系更为合适）来说明，IPrettyGirl接口代表了一个美女的标准，好的面容，好的身材，好的气质，星探就根据这些标准来发现美女，图4-1的类图是否合理？“情人眼里出西施”因此，每个时代不论个人还是大众的审美标准都在改变，比如唐代以胖为美，则好的身材这个美女标准可能就会有变化，再比如，有的没有GoodLooking，没有niceFigure，但是属于气质美女，所有，星探并不能随着大众的审美标准而与时俱进，则是因为该星探的抽象类，依赖于一个“庞大”（虽然只有三个方法）的接口，该接口容纳了一些可变的原则，星探应该依赖于具有某些特质的女孩子，因此有了图4-2中的类图结构，则此时星探可以寻找到气质美女，也能寻找到传统意义的美女。

图4-1图4-2

                                                                                           

3.示例引申：在单一职责的原则中如类图1-4中，IConnectManager是否可以继续进行拆分下去？挂电话有两种，一种为正常的电话挂断，一种为异常挂机，比如突然没电了，这两种方式的挂机处理应该是不同的，第一种对方收到挂机信号，计费系统停止计费，而第二种，是信号丢失，中继服务器检查到了，然后通知计费系统停止计费，这样考虑，是不是得把IConnectManager拆成两个？，一个负责连接，一个负责挂机？如果拆分了则不符合单一职责原则了，因为通信的建立和关闭已经是最小的业务单元了，再细分就是对业务或协议的拆分了，想想一个电话还得关心3G协议和中继服务器，则电话不能设计出来了。因此，根据接口隔离原则拆分接口时必须首先满足单一职责原则。

• 接口尽量小
• 接口高内聚，即尽量在接口中少公布public方法，接口是对外的承诺，承诺越少对系统开发越有利。
• 定制服务，单独为一个个体提供优良的服务。
• 接口设计是有限度的

图1-4

4.最佳实践：；

• 一个接口只服务于一个子模块儿和业务逻辑
• 通过业务逻辑压缩接口中的public方法
• 已经被污染了的接口，尽量去修改，若变更风险大，则用适配器模式去转化
• 了解环境，拒绝忙错