作者：Graham Lee
翻译：蜂猴
面向对象编程其实就是对于你的软件问题的一个基于对象之间的关联网和它们之间所发送的消息的一种描述。在iOS应用中，这种关联网络始于UIApplication实例，它会在程序开始时设置和加载一些框架对象，然后再告诉你的AppDelegate已经完成加载了。
AppDelegate是开发者建立应用功能及显示的初始地：Models，Views，Controllers从这里启始。但是这种关系应该不要太“生硬”。如果你应用中的对象对于外界的变化有太多的依赖，那么适应新需求，修复bug，添加功能和单独测试对于这样的对象来说将会很难。
什么是依赖注入，我为什么需要它？
之所以这样“生硬”的对象不好是因为你不能轻易地在App中对它们进行替换。如果一个对象对周围其他对象的加载有依赖，那么你也不能简单地告诉它应该使用另外一个对象。依赖注入可以解决这个问题：它会告诉该对象，“嘿，这里是你应该一起‘合作’的对象”，因此，如果我们想要改变合作者，我们只需要注入不同的东西。
这哪里有用了呢？在前一篇文章中,我提到了如何使用Mock（模仿）对象来作为生产对象的备用，以帮助设计它们的交互方式并消除测试中的一些复杂行为。这就是其中一个想要替换依赖对象的原因。另一个好处就是算法可以在多个上下文中重复使用，从不同来源接收数据并将结果传递到不同地方。为了更好理解这种情况，请想想iPod和音乐盒的区别。
音乐盒播放的旋律以凸点的形式被编码在转轴上。如果我们想用音乐盒播放不同的音乐，我们必须把整个音乐盒都拆开，然后替换转轴，再重新组装起来。相反的，iPod用USB接口来传输不同音乐就行。它只是作为音乐的播放器，具体的音乐内容又是很容易替换的。
音乐盒只有一个输出结构：金属针脚和转轴的凸点接触播放（乐器爱好者应该能认出这有点类似lamellophone）。因此如果要换曲子，那么还需要涉及到拆卸盒子和更换转轴。与此同时，iPod只有一个外置"插座"。任何与那个"插座"相兼容的"插头"或信号都可以传输到iPod进行播放。如果你用耳机听歌听厌了，想听广播，你只需要拔掉一个插头，然后插入另外一个，就已经成功将“依赖”注入到iPod中了。
回到程序中。依赖注入就是为了提高代码模块（比如类）的灵活性和适应性。那么再Objective-C中它是什么样的呢？
一个例子
想象以下代码是现有App中一个模块的代码。主要功能就是可以让我们可以浏览几个代码托管网站的主页。
@interface BNRCodeHostFetcher : NSObject
- (void)fetchGithubHome;
- (void)fetchBitbucketHome;
@end
@implementation BNRCodeHostFetcher
- (void)fetchGithubHome
{
NSURLSession *session = [NSURLSession sharedSession];
NSURLSessionDataTask *task = [session dataTaskWithURL:[NSURL URLWithString:@"http://www.github.com"] completionHandler:^(NSData *data, NSURLResponse *response, NSError *error){
NSDictionary *userInfo = @{ @"data": data,
@"response": response,
@"error": error };
[[NSNotificationCenter defaultCenter] postNotificationName:@"BNRGithubFetchCompletedNotification" object:self userInfo:userInfo];
}];
[task resume];
}
- (void)fetchBitbucketHome
{
NSURLSession *session = [NSURLSession sharedSession];
NSURLSessionDataTask *task = [session dataTaskWithURL:[NSURL URLWithString:@"http://www.bitbucket.org"] completionHandler:^(NSData *data, NSURLResponse *response, NSError *error){
NSDictionary *userInfo = @{ @"data": data,
@"response": response,
@"error": error };
[[NSNotificationCenter defaultCenter] postNotificationName:@"BNRBitbucketFetchCompletedNotification" object:self userInfo:userInfo];
}];
[task resume];
}
@end
从代码简洁及设计考虑，这个类的设计有些不太好的地方。比如有大量重复的代码，而且用Notification的形式来进行完成的回调也不太合理。从我们的依赖注入目的来说，最关键的是它对于一些对象有强烈的依赖：URLSession和notification center。如果我们想要单独测试这个类，我们需要使用Mock Object来替代这些对象，你可以想像一下，怎么更换URL Sesstion来获取不同的session配置，比如为了修改缓存策略。
以上，使用了Michael Feather的Working Effectively with Legacy Code中的命名方法，隐藏了依赖。如果你光看类的接口，你找不到任何东西能表明这个类和NSURLSession 或者NSNotificationCenter有依赖，但是事实上却是存在。
重构一点
第一个改动就是将这些共享对象的getter提出来，让这些依赖更明确一点（并顺便减少了一点点你重复的代码）。这虽然并没有本质上改善了依赖，但是我们还是先学走路，毕竟这个类还不是在测试环境。
@interface BNRCodeHostFetcher : NSObject
@property (nonatomic, readonly) NSURLSession *session;
@property (nonatomic, readonly) NSNotificationCenter *notificationCenter;
- (void)fetchGithubHome;
- (void)fetchBitbucketHome;
@end
@implementation BNRCodeHostFetcher
- (NSURLSession *)session
{
return [NSURLSession sharedSession];
}
- (NSNotificationCenter *)notificationCenter
{
return [NSNotificationCenter defaultCenter];
}
- (void)fetchGithubHome
{
NSURLSession *session = [self session];
NSURLSessionDataTask *task = [session dataTaskWithURL:[NSURL URLWithString:@"http://www.github.com"] completionHandler:^(NSData *data, NSURLResponse *response, NSError *error){
NSDictionary *userInfo = @{ @"data": data,
@"response": response,
@"error": error };
[[self notificationCenter] postNotificationName:@"BNRGithubFetchCompletedNotification" object:self userInfo:userInfo];
}];
[task resume];
}
- (void)fetchBitbucketHome
{
NSURLSession *session = [self session];
NSURLSessionDataTask *task = [session dataTaskWithURL:[NSURL URLWithString:@"http://www.bitbucket.org"] completionHandler:^(NSData *data, NSURLResponse *response, NSError *error){
NSDictionary *userInfo = @{ @"data": data,
@"response": response,
@"error": error };
[[self notificationCenter] postNotificationName:@"BNRBitbucketFetchCompletedNotification" object:self userInfo:userInfo];
}];
[task resume];
}
@end
现在这些依赖对象只有在getter方法里面会有影响：如果每次访问后返回的是不同的对象，也会进行使用。
我们继续沿用Michael Feather的术语，这些访问器在App的两个部分之间引入了一个‘接缝’。在这个例子中，‘接缝’是接在框架对象和使用框架的对象之间。
接下来要介绍的概念是注入点，一种利用‘接缝’的产物。在初始化方法中将这些类所关联的对象进行注入是其中一种方法。将我们刚才写的getter删除意味着这个类将会使用初始化方法中传入的对象，而不是之前那样自己所获取到的对象。这并不是唯一的办法，继承或者重写getter也可以。在本例中，我们能试试写一个自定义的初始化方法。
@interface BNRCodeHostFetcher : NSObject
@property (nonatomic, readonly) NSURLSession *session;
@property (nonatomic, readonly) NSNotificationCenter *notificationCenter;
- (instancetype)initWithURLSession:(NSURLSession *)session notificationCenter:(NSNotificationCenter *)center;
//...
@end
@interface BNRCodeHostFetcher ()
@property (nonatomic, strong, readwrite) NSURLSession *session;
@property (nonatomic, strong, readwrite) NSNotificationCenter *notificationCenter;
@end
@implementation BNRCodeHostFetcher
- (instancetype)initWithURLSession: (NSURLSession *)session notificationCenter: (NSNotificationCenter *)center
{
self = [super init];
if (self)
{
self.session = session;
self.notificationCenter = center;
}
return self;
}
- (instancetype)init
{
return [self initWithURLSession:[NSURLSession sharedSession]
notificationCenter:[NSNotificationCenter defaultCenter]];
}
//...
@end
启发
以上变动改完过后，App内的行为并没有发生改变：它还是通过init方法来进行初始化，这代表它使用的是默认的NSNotificationCenter 和 NSURLSession。但是现在这个类可以被很好的测试了，你可以使用OCMock 或者类似的工具去审查这个类的代码本身和其他依赖对象的协作关系。一旦你可以单独测试这个类，那么验证和纠正它行为就变得更容易了。
仅此而已？
是的，我手里也没什么藏的了，这就是依赖注入真正面目所在。正如James Shore所说依赖注入是：
用25块钱的术语形容了一个5分钱的概念。
尽管有许多依赖注入的框架存在，但是没有必要进行大量的工作来重新引入新的框架。所有你需要做的就是仔细审查一个对象，找出它所依赖的对象，然后决定如何让它与这些依赖对象更好交流。
