接口编程那些事

By 庞海礁 | 2015年12月8日

转载请注明出处:http://www.olinone.com/

接口是一系列可调用方法的集合。何为接口编程？接口编程是指当写一个函数或一个方法时，我们应该更加关注具体的接口，而不是实现类。具体理解可以参考这篇文章

在OC中，接口又可以理解为Protocol，面向接口编程又可以理解为面向Protocol编程，或者面向协议编程。在Swift中，苹果大幅强化了 Protocol 在这门语言中的地位，整个 Swift 标准库也是基于 Protocol 来设计的，有兴趣的童鞋可以看看这篇文章。面向接口编程正逐步成为程序开发的主流思想

在实际开发中，大多数朋友都比较熟悉对象编程，比如，使用ASIHttpRequest执行网络请求

ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];
[request setDidFinishSelector:@selector(requestDone:)];
[request setDidFailSelector:@selector(requestWrong:)];
[request startAsynchronous];

ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];

[request setDidFinishSelector:@selector(requestDone:)];

[request setDidFailSelector:@selector(requestWrong:)];

[request startAsynchronous];

request是请求对象，当发起请求时，调用者需要知道给对象赋哪些属性或者调用对象哪些方法。然而，使用AFNetworking请求方式却不尽相同

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
[manager GET:@"www.olinone.com" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
    NSLog(@"好网站，赞一个！");
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
    //to do
}];

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];

[manager GET:@"www.olinone.com" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {

NSLog(@"好网站，赞一个！");

} failure:^(AFHTTPRequestOperation *operation, NSError *error) {

//to do

}];

同是请求对象，使用AFNetworking发起请求时，调用者可以不需要关心它有哪些属性，只有接口无法满足需求时才需要了解相关属性的定义。两种设计思路完全不同，当然，此处并不是想表明孰优孰劣，只是想通过两种截然不同的请求方式引出本文的思想——面向接口编程（或者面向协议编程）

接口比属性直观

在对象编程中，定义一个对象时，往往需要为其定义各种属性。比如，ReactiveCocoa中RACSubscriber对象定义如下

@interface RACSubscriber ()

@property (nonatomic, copy) void (^next)(id value);
@property (nonatomic, copy) void (^error)(NSError *error);
@property (nonatomic, copy) void (^completed)(void);

@end

@interface RACSubscriber ()

@property (nonatomic, copy) void (^next)(id value);

@property (nonatomic, copy) void (^error)(NSError *error);

@property (nonatomic, copy) void (^completed)(void);

@end

参考AFNetworking的思想，以接口的形式提供访问入口

@interface RACSubscriber 

+ (instancetype)subscriberWithNext:(void (^)(id x))next 
                             error:(void (^)(NSError *error))error 
                         completed:(void (^)(void))completed;

@end

@interface RACSubscriber

+ (instancetype)subscriberWithNext:(void (^)(id x))next

error:(void (^)(NSError *error))error

completed:(void (^)(void))completed;

@end

通过接口的定义，调用者可以忽略对象的属性，聚焦于其提供的接口和功能上。程序猿在首次接触陌生的某个对象时，接口往往比属性更加直观明了，抽象接口往往比定义属性更能描述想做的事情

接口依赖

设计一个APIService对象

@interface ApiService : NSObject

@property (nonatomic, strong) NSURL        *url;
@property (nonatomic, strong) NSDictionary *param;

- (void)execNetRequest;

@end

@interface ApiService : NSObject

@property (nonatomic, strong) NSURL *url;

@property (nonatomic, strong) NSDictionary *param;

- (void)execNetRequest;

@end

正常发起Service请求时，调用者需要直接依赖该对象，起不到解耦的目的。当业务变动需要重构该对象时，所有引用该对象的地方都需要改动。如何做到既能满足业务又能兼容变化？抽象接口也许是一个不错的选择，以接口依赖的方式取代对象依赖，改造代码如下

@protocol ApiServiceProtocol <NSObject>

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param;

@end

@interface NSObject (ApiServiceProtocol) <ApiServiceProtocol>

@end

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
    ApiService *apiSrevice = [ApiService new];
    apiSrevice.url = url;
    apiSrevice.param = param;
    [apiSrevice execNetRequest];
}

@end

@protocol ApiServiceProtocol <NSObject>

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param;

@end

@interface NSObject (ApiServiceProtocol) <ApiServiceProtocol>

@end

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {

ApiService *apiSrevice = [ApiService new];

apiSrevice.url = url;

apiSrevice.param = param;

[apiSrevice execNetRequest];

}

@end

通过接口的定义，调用者可以不再关心ApiService对象，也无需了解其有哪些属性。即使需要重构替换新的对象，调用逻辑也不受任何影响。调用接口往往比访问对象属性更加稳定可靠

抽象对象

定义ApiServiceProtocol可以隐藏ApiService对象，但是受限于ApiService对象的存在，业务需求发生变化时，仍然需要修改ApiService逻辑代码。如何实现在不修改已有ApiService业务代码的条件下满足新的业务需求？

参考Swift抽象协议的设计理念，可以使用Protocol抽象对象，毕竟调用者也不关心具体实现类。Protocol可以定义方法，可是属性的问题怎么解决？此时，装饰器模式也许正好可以解决该问题，让我们试着继续改造ApiService

@protocol ApiService <ApiServiceProtocol>

// private functions

@end

@interface ApiServicePassthrough : NSObject

@property (nonatomic, strong) NSURL        *url;
@property (nonatomic, strong) NSDictionary *param;

- (instancetype)initWithApiService:(id<ApiService>)apiService;
- (void)execNetRequest;

@end

@protocol ApiService <ApiServiceProtocol>

// private functions

@end

@interface ApiServicePassthrough : NSObject

@property (nonatomic, strong) NSURL *url;

@property (nonatomic, strong) NSDictionary *param;

- (instancetype)initWithApiService:(id<ApiService>)apiService;

- (void)execNetRequest;

@end

@interface ApiServicePassthrough ()

@property (nonatomic, strong) id<ApiService> apiService;

@end

@implementation ApiServicePassthrough

- (instancetype)initWithApiService:(id<ApiService>)apiService {
    if (self = [super init]) {
        self.apiService = apiService;
    }
    return self;
}

- (void)execNetRequest {
    [self.apiService requestNetWithUrl:self.url Param:self.param];
}

@end

@interface ApiServicePassthrough ()

@property (nonatomic, strong) id<ApiService> apiService;

@end

@implementation ApiServicePassthrough

- (instancetype)initWithApiService:(id<ApiService>)apiService {

if (self = [super init]) {

self.apiService = apiService;

}

return self;

}

- (void)execNetRequest {

[self.apiService requestNetWithUrl:self.url Param:self.param];

}

@end

经过Protocol的改造，ApiService对象化身为ApiService接口，其不再依赖于任何对象，做到了真正的接口依赖取代对象依赖，具有更强的业务兼容性

定义一个Get请求对象

@interface GetApiService : NSObject  <ApiService>

@end

@implementation GetApiService

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
    // to do
}

@end

@interface GetApiService : NSObject <ApiService>

@end

@implementation GetApiService

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {

// to do

}

@end

请求代码也随之改变

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
    id<ApiService> apiSrevice = [GetApiService new];
    ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];
    apiServicePassthrough.url = url;
    apiServicePassthrough.param = param;
    [apiServicePassthrough execNetRequest];
}

@end

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {

id<ApiService> apiSrevice = [GetApiService new];

ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];

apiServicePassthrough.url = url;

apiServicePassthrough.param = param;

[apiServicePassthrough execNetRequest];

}

@end

对象可以继承对象，Protocol也可以继承Protocol，并且可以继承多个Protocol，Protocol具有更强的灵活性。某一天，业务需求变更需要用到新的Post请求时，可以不用修改 GetApiService一行代码，定义一个新的 PostApiService实现Post请求即可，避免了对象里面出现过多的if-else代码，也保证了代码的整洁性

依赖注入

文章写到这里，细心的童鞋可能已经发现问题——GetApiService依然是以对象依赖的形式存在。如何解决这个问题？没错，那就是依赖注入！

依赖注入是什么？借用博客里面的一句话，其最大的特点就是：帮助我们开发出松散耦合、可维护、可测试的代码和程序。这条原则的做法是大家熟知的面向接口，或者说是面向抽象编程。 objc上这篇文章介绍的不错，有兴趣的童鞋也可以看看，在此就不再累述

基于依赖注入objection开源库的基础上继续改造ApiService

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
    id<ApiService> apiSrevice = [[JSObjection createInjector] getObject:[GetApiService class]];
    ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];
    apiServicePassthrough.url = url;
    apiServicePassthrough.param = param;
    [apiServicePassthrough execNetRequest];
}

@end

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {

id<ApiService> apiSrevice = [[JSObjection createInjector] getObject:[GetApiService class]];

ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];

apiServicePassthrough.url = url;

apiServicePassthrough.param = param;

[apiServicePassthrough execNetRequest];

}

@end

调用者关心请求接口，实现者关心需要实现的接口，各司其职，互不干涉

接口和实现分离的设计适用于团队协作开发，实现了系统的松散耦合，便于以后升级扩展。当然，接口编程对开发人员的要求也比较高，需要提前定义好接口，接口一变，全部乱套，这就是所谓的设计比实现难，但是设计接口的人工资都高啊！！！

2015/12/20，许多朋友希望出个demo，特此补上。另阿里音乐正在招聘iOS高级开发工程师，有兴趣的朋友可以微博或者网页下面跟我留言内推哦！

后记：你可以在github找到我，也可以通过微博联系我，感谢你的来访！

42 thoughts on “接口编程那些事”

匿名 2015年12月8日

赞一个

Reply ↓
匿名 2015年12月9日

楼主你好，能否提供一个你的demo，十分感谢。

Reply ↓
1. 庞海礁 Post author2015年12月9日
  
  谢谢你的建议，其实是想写个的，时间仓促，以后补上
  
  Reply ↓
匿名 2015年12月9日

你好，能否提供一个demo来参考下，由于设计模拟不是太熟悉，在改造为post的时候需要具体怎么处理呢。

Reply ↓
杨兵 2015年12月9日

hi,如果业务升级的话,就算接口不变,扩展性我觉得挺好的,
原有的业务逻辑我觉得还是要改啊,
目前还没遇到过面向接口的设计方案,确实没有感受到好处与不足,
文章还好,简单,易入门.
谢谢

Reply ↓
1. 庞海礁 Post author2015年12月9日
  
  业务升级，只要接口不变，定义一个新的业务对象实现协议即可，就好比定义一个新的PostApiService对象一样，原GetApiService可以不用修改一行代码，也没有所谓的父类继承或者各种判断属性的定义
  
  Reply ↓
  1. 沈源 2017年5月17日
    
    楼主你好，看了你的博客还是有个疑问就是传入url和param参数后怎么获得网络请求的回调内容在vc里调用是用代理返回吗
    
    Reply ↓
91jufan 2015年12月14日

这个可以有！

Reply ↓
匿名 2015年12月15日

抽象对象这一块，感觉不是很能理解

Reply ↓
1. 庞海礁 Post author2015年12月15日
  
  简单理解为接口替换对象，将具体对象隐藏起来，以接口的方式对外提供访问入口，不直接依赖具体对象
  
  Reply ↓
Warden 2015年12月16日

楼主文章写的很赞, 提供一个Demo就完美了。

Reply ↓
lok.mm 2015年12月21日

最后一个的- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param方法可以改为类方法名字加上GET嘛，以后的网络获取只用这一个吗

Reply ↓
1. 庞海礁 Post author2015年12月21日
  
  改成类方法的想法不错，可以考虑下。名字加不加上get不重要，这只是一个demo，不过为每一个接口取一个好名字的想法值得倡导，加油哦！
  
  Reply ↓
yiluyingxiao 2015年12月29日

提前祝您新年快乐。
乙未年(羊)冬月十九 2015-12-29

Reply ↓
17447072 2016年1月5日

看看！

Reply ↓
软件 2016年1月12日

到此一游!

Reply ↓
刘力硕 2016年1月13日

你好，请问最后用注入的意义在哪里？我觉得并没有实现解耦吧，我们还是要知道具体的类，导入头文件才行，[[JSObjection createInjector] getObject:[GetApiService class]]; 这个是不是要换成用协议来取对象才真正解耦了？初次接触这方面的东西，请指点一下哈。

Reply ↓
1. 庞海礁 Post author2016年1月13日
  
  其实你能提出这个问题说明你已经懂得了依赖注入，当时写demo时为了图简单，就直接通过[GetApiService class]获取该对象，从而误导了大家。正常情况下，此处我们只需要获取到遵从该协议的对象就行了，所以可以使用Objection库的protocol的方式获取GetApiService对象，你可以尝试下
  
  Reply ↓
liulishuo 2016年1月13日

你好，请问最后为了解耦的注入有什么作用？我觉得并没有实现解耦，因为还是要导入具体类的头文件，然后用[[JSObjection createInjector] getObject:[GetApiService class]] 取出来，这样和自己直接new没有区别吧？是不是应该用协议来取，而不是用class来取会好一点？初次接触这方面的知识，请多指教哈~

Reply ↓
1. 庞海礁 Post author2016年1月13日
  
  对，这个最好用协议来取，赞一个，当初偷懒把大家给误导了
  
  Reply ↓
liulishuo 2016年1月13日

不好意思我这里卡了发了两遍^_^ 谢谢楼主回复~

Reply ↓
Joe 2016年1月21日

您好，您的文章写的非常棒，但是我有个疑问，就是在最后调用的地方
@implementation NSObject (ApiServiceProtocol)
– (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
id apiSrevice = [GetApiService new];
ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];
apiServicePassthrough.url = url;
apiServicePassthrough.param = param;
[apiServicePassthrough execNetRequest];
}
@end
这里为什么还需要使用ApiServicePassthrough将apiService包一层，而不是直接这样做：
– (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
id apiSrevice = [GetApiService new];
// ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];
// apiServicePassthrough.url = url;
// apiServicePassthrough.param = param;
// [apiServicePassthrough execNetRequest];
[apiService requestNetWithUrl:self.url Param:self.param];
}

Reply ↓
1. 庞海礁 Post author2016年1月21日
  
  这个文中其实已经说过了，apiservice是实体对象，ApiServicePassthrough是它的一个抽象体，因为我们拒绝直接依赖。其次，抽象接口后可以适配不同的实现对象，以后有新的解决方案时，可以做到零切换成本，上层业务逻辑不需要修改任何代码，其永远只关心装饰器接口那层，做到上层和底层的业务抽离
  
  Reply ↓
57096 2016年2月5日

年前再来转转！

Reply ↓
Pingback: iOS开发见闻-第15期 - IT大道
匿名 2016年3月23日

@protocol ApiService
这一个接口的继承是多余的吧，直接使用ApiServiceProtocol就可以了啊

Reply ↓
1. 庞海礁 Post author2016年3月23日
  
  没记错的话，当时写ApiService是为了支持更多功能用的吧，忘记了
  
  Reply ↓
匿名 2016年3月23日

你好

Reply ↓
小鸡啄蘑菇 2016年4月3日

看了文章，也clone了demo，但还是无法理解跟体会其中的思想跟好处。。。关于DI，看了楼主添加的外链文章，天马行空，完全看不懂。。好郁闷啊博主 -. –

Reply ↓
1. 庞海礁 Post author2016年4月5日
  
  刚接触可能有点陌生，需要慢慢体会吧，多看看多想想，不能急的
  
  Reply ↓
Pingback: 谈谈依赖注入与面向接口编程思想 | 神刀安全网
1. 庞海礁 Post author2016年4月13日
  
  写的不错，赞一个!
  
  Reply ↓
chaos 2016年5月13日

装饰器模式在ReactiveCocoa里面有很深刻的使用，在ApiServicePassthrough的头文件中暴露url和param没必要，外部并不需要获取这两个参数，通过init方法参数传就好了。最后依赖注入那块，博主的Demo是难以实现的，接口和实现接口的主体应该是唯一绑定的，而Demo中GetApiService和PostApiService实现的是同一个协议。

Reply ↓
1. 庞海礁 Post author2016年5月14日
  
  ApiServicePassthrough中的url和param相当于属性角色，是允许修改和赋值的，通过init初始化当然可以，就是失去了作为属性的职责。关于依赖注入这个，一个接口可以有多个实现，就看你提前注入啥了！
  
  Reply ↓
匿名 2016年8月11日

写的很好,虽然现在不是很懂,好好研究一下.

Reply ↓
1. 庞海礁 Post author2016年8月11日
  
  有什么疑问都可以留言！*-*
  
  Reply ↓
Pingback: 谈谈依赖注入与面向接口编程 – 项目经验积累与分享
Pingback: iOS开发见闻-第15期 – 项目经验积累与分享
沈源 2017年5月17日

请问在传入url和param和两个参数后网络请求回调的内容在VC里怎么获得是在协议里传入返回值吗

Reply ↓
沈源 2017年5月17日

楼主你好，看了你的博客还是有个疑问就是传入url和param参数后怎么获得网络请求的回调内容在vc里调用是用代理返回吗

Reply ↓
匿名 2017年5月18日

楼主你好，看了你的博客还是有个疑问就是传入url和param参数后怎么获得网络请求的回调内容在vc里调用是用代理返回吗

Reply ↓
1. 庞海礁 Post author2017年5月20日
  
  使用block回调
  
  Reply ↓

接口比属性直观

接口依赖

抽象对象

依赖注入

42 thoughts on “接口编程那些事”

发表回复 取消回复

发表回复取消回复