定义
The dependency of one class to another one should depend on the smallest possible interface.
类间的依赖关系应该建立在最小的接口上
它要求是最小的接口，也是要求接口细化，接口纯洁。
概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗的说就是接口尽量细化，同时接口中的方法尽量少。
接口隔离原则要求接口的方法尽量少。
场景模拟
假设你是追星族，每天都在追美女明星。
场景模拟UML图
简单代码
@protocol Starts<NSObject>
-(void)goodLooking;
-(void)niceFigure;
@end
#import "Starts.h"
@protocol FindStarts<NSObject>
-(void)findStarts:(id)start;
-(void)show;
@end
#import "FindStarts.h"
@interface Xiaoming : NSObject<FindStarts>
@end
#import "Xiaoming.h"
@interface Xiaoming()
@property (nonatomic,strong) id<Starts>start;
@end@implementation Xiaoming
-(void)findStarts:(id<Start>)start{
self.start = start;
}
-(void)show{
[self.start goodLooking];
[self.start niceFigure];
}
@end
#import "Starts.h"
@interface XuJIaoStart : NSObject<Starts>
@end
@implementation XuJIaoStart
-(void)goodLooking{
NSLog(@"徐娇有很好看的长相");
}
-(void)niceFigure{
NSLog(@"徐娇有好身材");
}
@end
测试代码
id<FindStarts> xiaoming = [Xiaoming new];
id<Starts> xujiao = [XuJIaoStart new];
[xiaoming findStarts:xujiao];
[xiaoming show];
测试结果
2018-04-04 10:39:23.748776+0800 设计模式原则[30377:6025494] 徐娇有很好看的长相
2018-04-04 10:39:23.748961+0800 设计模式原则[30377:6025494] 徐娇有好身材
场景变更
假设我们对明星的标准有所改变，不在单纯的定义认为长相和身材好的明星。只有其中之一就可以了。那上面的代码就不能适应变化了，这主要是因为接口庞大，没有尽量细化。根据接口隔离原则，我们把这两个元素拆分。
场景变更UML图
场景变更代码
#import "StartsA.h"
#import "StartsB.h"
@protocol FindNewStarts<NSObject>
-(void)findStartsA:(id<StartsA>)start;
-(void)findStartsB:(id<StartsB>)start;
-(void)show;
@end
@protocol StartsA<NSObject>
-(void)goodLooking;
@end
@protocol StartsB<NSObject>
-(void)niceFigure;
@end
#import "FindNewStarts.h"
@interface XiaoHei : NSObject<FindNewStarts>
@end
#import "XiaoHei.h"
@interface XiaoHei()
@property (nonatomic,strong) id<StartsA>startA;
@property (nonatomic,strong) id<StartsB>startB;
@end
@implementation XiaoHei
-(void)findStartsA:(id<StartsA>)start{
self.startA = start;
}
-(void)findStartsB:(id<StartsB>)start{
self.startB = start;
}
-(void)show{
[self.startA goodLooking];
[self.startB niceFigure];
}
@end
#import "StartsA.h"
#import "StartsB.h"
@interface XuJiaoNewStart : NSObject<StartsA,StartsB>
@end
#import "XuJiaoNewStart.h"
@implementation XuJiaoNewStart
-(void)goodLooking{
NSLog(@"徐娇有很好看的长相");
}
-(void)niceFigure{
NSLog(@"徐娇有好身材");
}
@end
测试代码
id<FindNewStarts> xiaohei = [XiaoHei new];
XuJiaoNewStart * xujiao = [XuJiaoNewStart new];
[xiaohei findStartsB:xujiao];
[xiaohei findStartsA:xujiao];
[xiaohei show];
结果
2018-04-04 10:39:23.748776+0800 设计模式原则[30377:6025494] 徐娇有很好看的长相
2018-04-04 10:39:23.748961+0800 设计模式原则[30377:6025494] 徐娇有好身材
其实我们这里规定了徐娇是两者都符合的标准明星，其实也可以实现一个就可以了。这样扩展会更灵活些。
保证接口的纯洁性
接口隔离原则是对接口进行规范约束
1.接口要尽量小
这是接口隔离原则的核心定义，接口要尽量小，不要出现臃肿的接口，但是小也是有限度的，不能违背单一职责原则。
2.接口要高内聚
高内聚就是提高接口，类，模块的处理能力，减少对外的交互。具体到接口隔离原则就是要求在接口中尽量减少公布public方法，接口是对外的承诺，承诺越少对系统开发越有利，变更的风险就越少。
3.接口设计是有限度的
接口的设计粒度越小，系统越灵活。但是灵活的同时也带来了结构复杂，开发难度大，可维护性降低。所以接口设计要注意适度。
接口隔离原则开发经验
接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。我们在实践中可以以下几个规则来衡量：
一个接口只服务于一个子模块或业务逻辑
通过业务逻辑压缩接口中的public方法，接口要不断的精简，以达到接口不断完善
已经被污染的接口，尽量去修改，若变更的风险较大，则采用适配器进行转化处理
谈谈学习接口隔离原则的感想
设计接口的粒度越小，系统越灵活是肯定的。但是过度把接口设计粒度锁到很小，这样会增加系统阅读代码的复杂度。接口设计尽量使其能完成一个特有的功能，而不能把一个功能再进行拆分，拆分出好多接口来，这就过度设计了，度很难把握。
参考博客
下一篇博客
