七、设计模式的六大设计原则之接口隔离原则(ISP, Interf
1. 何为接口隔离原则
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
定义解读：
该定义包含以下三层含义：
a. 一个类对另一个类的依赖应该建立在最小的接口上；
b. 一个接口代表一个角色，不应该将不同的角色都交给一个接口，因为这样可能会形成一个臃肿的大接口；
b. 不应该强迫客户端依赖他们从来不用的方法。
接口隔离原则有点像单一职责原则，但是也有区别，在单一职责原则中，一个接口可能有多个方法，提供给多种不同的调用者所调用，但是它们始终完成同一种功能，因此它们符合单一职责原则，却不符合接口隔离原则，因为这个接口存在着多种角色，因此可以拆分成更多的子接口，以供不同的调用者所调用。比如说，项目中我们通常有一个Web服务管理的类，接口定义中，我们可能会将所有模块的数据调用方法都在接口中进行定义，因为它们都完成的是同一种功能：和服务器进行数据交互；但是对于具体的业务功能模块来说，其他模块的数据调用方法它们从来不会使用，因此不符合接口隔离原则。
优点
使用接口隔离原则，意在设计一个短而小的接口和类，符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。
2. 情景设置
类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类C来说不是最小接口，而类B和类D必须去实现它们不需要的方法。下面通过一个UML图来说明这种现象，如图2-1所示：
图2-1
在这里，我们定义了一个动物活动的接口IAnimal，里面有4个方法：飞行fly、行走walk、吃eat和工作work，然后分别用人类People和鸟类Bird实现了这个接口。中国人类ChinesePeople和鹦鹉类Parrot通过接口IAnimal分别依赖类People和类Bird。很明显，对于ChinesePeople来说，fly方法是多余的，因为人不会飞；对于Parrot类来说，work方法是多余的，因为鹦鹉不需要工作。接口IAnimal对于类ChinesePeople和类Parrot来说不是最小接口。
解决方案
将臃肿的接口IAnimal拆分为独立的几个接口，类ChinesePeople和类Parrot分别与它们需要的接口建立依赖关系，也就是采用接口隔离原则。修改后的UML图如图2-2所示：
图2-2
3. 代码实现
（1）三个接口
@protocol IAnimal <NSObject>
//- (void)work; // 使用接口隔离原则，将该方法放到其他接口
//- (void)fly; // 使用接口隔离原则，将该方法放到其他接口
@optional
- (void)walk;
@required
- (void)eat;
@end
@protocol IPeople <NSObject>
- (void)work;
@end
@protocol IBird <NSObject>
- (void)fly;
@end
（2）People
@interface People : NSObject<IAnimal,IPeople>
@end
@implementation People
- (void)work
{
NSLog(@"I am working");
}
//- (void)fly
//{
// NSLog(@"I am flying");
//}
- (void)walk
{
NSLog(@"I am walking");
}
- (void)eat
{
NSLog(@"I am eating");
}
@end
（3）Bird
@interface Bird : NSObject<IAnimal,IBird>
@end
@implementation Bird
//- (void)work
//{
// NSLog(@"I am working");
//}
- (void)fly
{
NSLog(@"I am flying");
}
- (void)walk
{
NSLog(@"I am walking");
}
- (void)eat
{
NSLog(@"I am eating");
}
@end
（4）ChinesePeople
@interface ChinesePeople : NSObject
@property (nonatomic,assign) id<IAnimal> animalDelegate;
@property (nonatomic,assign) id<IPeople> peopleDelegate;
@end
@implementation ChinesePeople
@synthesize animalDelegate = _animalDelegate;
@synthesize peopleDelegate = _peopleDelegate;
- (void)work
{
// [_animalDelegate work];
[_peopleDelegate work];
}
//- (void)fly
//{
// [_animalDelegate fly];
//}
- (void)walk
{
[_animalDelegate walk];
}
- (void)eat
{
[_animalDelegate eat];
}
@end
（5）Parrot
@interface Parrot : NSObject
@property (nonatomic,assign) id<IAnimal> animalDelegate;
@property (nonatomic,assign) id<IBird> birdDelegate;
@end
@implementation Parrot
@synthesize animalDelegate = _animalDelegate;
@synthesize birdDelegate = _birdDelegate;
//- (void)work
//{
// [_animalDelegate work];
//}
- (void)fly
{
// [_animalDelegate fly];
[_birdDelegate fly];
}
- (void)walk
{
[_animalDelegate walk];
}
- (void)eat
{
[_animalDelegate eat];
}
@end
（6）客户端调用
ChinesePeople *chinesePeople = [[ChinesePeople alloc] init];
People *people = [[People alloc] init];
chinesePeople.animalDelegate = people;
chinesePeople.peopleDelegate = people;
[chinesePeople work];
[chinesePeople eat];
[chinesePeople walk];
从UML图可以看到，遵守接口隔离原则，会使代码量增加不少，源码中也是这样；实际上，iOS在定义协议的时候，可以设置方法为可选实现(@optional)和必须实现(@required，默认值)，我们可以设置work方法和fly方法为可选实现的方法，这样在类People和类Bird中，这两个方法可以根据需要来决定是否实现。采用这种方式，功能上实现是没有问题，对于简单的接口来说，也便于维护和管理。但是，当方法随着业务需求的增加而不断增加的话，如果我们不应用接口隔离原则，那么就可能形成一个庞大臃肿的接口，这样的接口的可维护性和重用性是很差的。因此，我们应该尽量细化接口，本篇将一个接口变更为3个专用的接口所采用的就是接口隔离原则。在项目开发中，依赖几个专用的接口要比依赖一个综合的接口更加灵活。通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
虽然接口隔离原则很有意义，但在实际项目中，应该注意度的把握，接口设计的过大或过小都不好，应该根据实际情况多思考再进行设计。
