谈谈依赖注入与面向接口编程思想

依赖注入(Dependency Injection)

今天我们讨论的内容核心是面向接口编程，我决定还是要从依赖注入开始讲起，因为DI的思想可以说是面向接口编程思想的特殊表现，也可以说是与面向接口编程相辅相成。先撇开让人头脑发晕的文字定义，我们还是用我们最忠实和伙伴——代码来了解依赖注入。我们先来一个粗略的例子，由浅入深： 我们有一个公交车类(Bus)，每天早上6点钟需要发车(work)，为其分配对应的司机(Driver)，看代码

@implementation Bus  - (void)work {     Driver *driver = [[Driver alloc] initWithName:@"张三"];     //dosomething } @end 

在上面这段代码中，Bus对象的运作需要用到Driver对象，因而创建了一个Driver对象，我们称Bus对Driver有一个依赖。这样的强耦合关系会因为日后的变化而给我们带来很多麻烦，不久将来张三师傅辞职了，我们需要修改Bus-work()的代码，也就是说在开发过程中非常不便于单元测试(一是不能方便地更换各种Driver对象，二是如果Driver这个职位创建是耗时操作或者高成本操作，我们并不能使用准备好的Driver实现快速重复测试)。 我们继续:

@implementation Bus  @property (strong, nonatomic) Driver *driver; - (instancetype)initWithDriver:(Driver *)driver {     self = [super init];     if (self) {         self.dirver = driver;     }     return self; } - (void)work {     //dosomething } @end 

以上这段代码我们通过init方法，为Bus对象传入了一个Driver对象，像这种非自己主动初始化依赖，而从外部通过注入点注入依赖的方式，我们就称为依赖注入，而例子中的这种注入的方法称之为构造器注入。明显的，这个场景中Bus和Driver的耦合因此轻了一层。说到解耦，并不是说Bus和Driver之间的依赖关系就不存在了，在Bus的范围内看来，只是将依赖建立从编译期间推迟到了运行期间，毕竟Bus无论如何也是需要Driver提供服务的。对此， 这篇文章 有一个非常形象的比喻，“依赖就像是系统中的plugin，主系统并不强依赖于任何一个插件，但一旦插件被加载，主系统就应该可以准确调用适当插件的功能”。

类似这样的注入方式还有

• 属性注入
• 方法注入
• 环境上下文注入
• 子类重写方法注入等

不同的只是注入的手段，思想还是一样的。

轻轻地思考

组件化

也是objc的 那篇文章 中提到一种叫做 “pluggable排插思想” ，用原话来说，如果一个类的initializer需要提供一个 id<foo> 的参数，说明我们需要为之提供一个遵守foo协议的对象才可以让这个类运作起来，有没有发现DI外衣下的 面向接口思想 的肉体？所以说更深层的，DI的一个目标是为了实现组件化架构，DI让依赖更加明显，DI划定了组件的边界和组件的组装方式。

开闭原则(Open-Closed Principle)

这里要带入一个比较重要的思想——OCP，国内比较少笔墨对OCP思想的介绍和强调，他的原文解释是Software entities should be open for extension,but closed for modification，对扩展开放，对修改关闭。也就是说我们对模块的设计，应该满足将来在不可修改源代码的情况下对模块的职能扩展，或者改变模块的行为。单单这句话就能表现出OCP可怕的地位，他迫使我们主动考虑了将来，使应用保证了核心代码的稳定性和对新需求的灵活性。

依赖获取(Dependency Locate)

更高级的依赖注入

//定义一个主题接口，让所有主题都实现它 @protocol ItfThemeFactory <NSObject> - (void)drawing; @end  //主题 @implementation SpringFactory <ItfThemeFactory> - (void)drawing {     //drawing theme... } @end  @implementation SummerFactory <ItfThemeFactory> - (void)drawing {     //drawing theme... } @end  //主题工厂Animator @interface ThemeFactoryAnimator : NSObject @property (strong, nonatomic) id<ItfThemeFactory> themeFactory; @end @implementation ThemeFactoryAnimator - (id<ItfTheme>)themeFactory {     NSString *path = [[NSBundle mainBundle] pathForResource:@"theme" ofType:@"plist"];     NSDictionary *dict = [[NSDictionary alloc] initWithContentsOfFile:path];     NSString *theme = [dict objectForKey:@"theme"];     if ([theme isEqualToString:@"spring"]) {         _themeFactory = [[SpringFactory alloc] init];     } else if ([theme isEqualToString:@"summer"]) {         _themeFactory = [[SummerFactory alloc] init];     } else {         //assert     } } @end  //在执行方法里我们要做什么？ - (void)work {     ThemeFactoryAnimator *tfAnimator = [ThemeFactoryAnimator alloc] init];     id<ItfThemeFactory> themeFactory = tfAnimator.themeFactory;     [themeFactory drawing]; } 

以上，我们只需要在执行方法(-work())中拿到themeFactory，对界面进行渲染即可，而原本有可能出现依赖的地方——ThemeFactoryAnimator已经不依赖于外部注入，而仅仅依赖于我的theme.plist配置文件，也可以说我们将多态封装到了这个“获取点”内，因此主题的改变映射到了配置文件中对应内容的改变，但是这个更换主题系统目前就利用DI变得符合OCP原则了吗？不是的，虽然依赖的改变已经映射到了客户类封装的外部——配置文件中，可是我们还是无法避免if-else结构的存在，我们可以不修改代码自由更换主题，可是如果又开发出了一套新的主题呢？这个系统对于未来还是无能为力，这一part的重点是依赖获取，至于怎么消除这种缺陷？看完这篇文章也许你就自然明白了。

面向接口编程(Protocol-oriented programming)

我们是时候谈谈面向接口了，如果对笔者上面说的还没能很好理解没关系，思想的认识需要时间去沉淀、矫正，出来的才是真理。首先我们怎样定义接口：“接口泛指实体把自己提供给外界的一种抽象化物，用以由内部操作分离出外部沟通方法，使其能被修改内部而不影响外界其他实体与其交互的方式”，换句话说，在我们程序的世界里，接口的作用就是用于定义一个或一组规则，实现对应接口的实体需要遵守对应的这些规则。也可以说是对“同类事物”的抽象表示，而“同类事物”的界定就看是否实现了同一个接口，譬如有一个Animal接口和一个NightWorking接口,公鸡实现了Animal接口，猫头鹰实现了Animal接口和NightWorking接口，还有一个实现了NightWorking接口的路灯，在Animal的范畴下，我们可以称公鸡和猫头鹰是同类事物，而在NightWorking的范畴下，我们可以称猫头鹰和路灯是同类事物。。。。相对的东西真恐怖，不知道笔者什么时候会跟什么东西被划分为同类。。。

面向接口编程(编码)

面向接口比较抽象，也比较广泛，它不仅仅是指一个定性的东西，我们可以从POP为程序带来的一个一个优越性为切入点研究，下面继续是一个简单的例子，让我们来感受下POP思想的初衷:这次还是拿交通工具来说，

//首先我们定义一个交通工具接口 @protocol Transportation <NSObject> - (void)drinking; - (void)freight; @end //还有一个发光体接口   @protocol Irradiative <NSObject> - (void)shine; @end //当然drinking就代表补需，汽车飞机的内部实现就是加油，马牛的内部实现就是吃草喝水什么的。freight就是装载  //当上帝创造马的时候，让马遵守并实现这个接口: @implementation Horse <Transportation>   - (void)drinking {     //吃草，喝果汁 }  - (void)freight {     //停住脚步，或者半蹲，让友好的人类骑上去 } @end //当人类创造飞机的时候，惨了，不知道去哪里找上帝沟通，又怕疏漏了什么影响了这个世界的运行规律？没事上帝给我们留下了Transportation接口，而且飞机同时还要遵守发光体接口Irradiative，于是：   @implementation Aircraft <Transportation, Irradiative>   - (void)drinking {     //加油, 92的 }  - (void)freight {     //降落，熄火，开舱门 }  - (void)shine {     //燃烧汽油，生物质能转化成电能，照你 } @end 

当然物理学上能通过转化其他物质发出可见光的也不一定叫发光体，已经毕业了就容我不按规矩来吧。以上，因为我们按规矩办事，制造出来的飞机从来没有自爆过。而马匹也重来不需要死机重启。感觉很有道理！如果不久将来我们着手创造时空穿梭机，我们第一步工作，就是要让其遵守实现Transportation接口等，如果我们要求这个穿梭机还能帮我们敲代码，我们继续让其遵守objcAble接口。

面向接口编程(架构)

不知不觉文章篇幅已经比较大了，让我们来再往上爬一层，让POP应用于更大的一个领域，甚至改变架构，虽然上一part已经算是一种架构思想，但是笔者更希望表现的是他在编码应用中的优越性，而这一part将赋予POP在大型项目中不可撼动的地位。

无论是哪种架构方式，层次关系肯定是撇不开的，并且层次关系也代表着一种架构的主心骨，无论业务分层，功能分层，还是角色分层，存在于各个位置的依赖关系都需要我们去正视，而POP的目的正是为了化解这些强依赖，打破上层实例化下层去为其提供服务的强耦合，在大型项目中，一层的变化可能会联动1+N层，这样的变化是致命的，正如上文我们提到过的，让一个实体由依赖另一个实体，转变成依赖一个接口，将被依赖实体的变化隔绝于接口之外。

补充一句，这里的接口指代的并不是上一part中实体化的"接口"，而是相对意义上的接口，一种思想！

iOS实际生产中的接口编程

不知道大家看了“面向接口编程(编码)”后，有没有发现日常OC编码中似乎随处可见接口编程的痕迹？——侵蚀了我们项目各个模块的代理模式，代理模式的工作原理就是，一方使用protocol(接口)划定一个或一组规则，成为其代理的角色必须遵守这一系列规则，最后根据规则去办事，好处依然是那么明显，主体并不需要与代理沟通，代理也不需要做多余的培训，直接上岗，从这里又强化了一遍接口即一种由内部操作分离出外部沟通方法，而核心就是一系列规则，通过接口工作，比直接访问属性或者方法稳健得多。

而这一part中我们的主题并不是这个，为了思想上的升华，这里给出一个简单例子，这里例子参考 庞海礁师兄文章例子 变换而来，讲到那种相对意义上的接口思想。

#pragma mark - 面向对象传统的方式： //服务实现者 甲方 ，编写一个服务类 @interface MusicLoadingProtocolObj() @end @implementation MusicLoadingProtocolObj - (void)requestWithUrl:(NSURL *)url Param:(NSDictionary *)param {     //do something } @end  //服务使用者 乙方 ，通过接口获取服务类 #import "MusicLoadingProtocolObj.h" @interface Client() @end @implementation Client - (void)work {     MusicLoadingProtocolObj *musicLoadingProtocolObj = [MusicLoadingProtocolObj alloc] init];     [musicLoadingProtocolObj requestWithUrl:url Param:param]; } @end //当然，在这里我们已经应用了构造器注入的DI思想。或者我们如果使用属性注入？那么当然就没那么直观，没有贯彻接口编程的思想。   #pragma mark - 接下来就是面向接口(POP)的做法： //首先，定义一个ServiceProtocol @protocol MusicLoadingProtocol <NSObject> - (void)requestWithUrl:(NSURL *)url Param:(NSDictionary *)param; @end  //甲方 @interface MusicLoadingProtocolObj() <MusicLoadingProtocol> @end @implementation MusicLoadingProtocolObj - (void)requestWithUrl:(NSURL *)url Param:(NSDictionary *)param {     //do something } @end  //乙方 @interface Client() @end @implementation Client - (void)work {     id<MusicLoadingProtocol> service = [[JSObjection defaultInjector] getObject:@protocol(MusicLoadingProtocol)];     [service requestWithUrl:url Param:param]; } @end 

上例中笔者借助了OC的一个轻量级的DI框架objection，服务实现者甲方独立编写服务实现，而后将服务通过objection绑定到protocol之上，去看看服务使用者，乙方利用objection通过protocol拿到服务类实例，根据protocol中定义的规则，马上就实现了服务。不需要import，不需要实例化，高度解耦，并且符合OCP原则。objection的原理就是上文提到的key-value内存映射表，对于大型项目，多小组分项目开发再合并的生产线，POP是必不可少的。

如果说我们在轻型开发中不想使用框架，我们也可以谈谈自己实现POP+DI，利用起OC的利器——runtime。其实在上例已经埋下伏笔，这次我们的乙方可以这样做：

//乙方 @interface Client() @end @implementation Client - (void)work {     NSString *clazzName = @"MusicLoadingProtocol";     [clazzName stringByAppendingString:@"Obj"];     Class serviceClazz = NSClassFromString(@"clazzName");     id<MusicLoadingProtocol> service = [serviceClazz alloc] init];     [service requestWithUrl:url Param:param]; } @end 

就是这样，甲乙双发约定了以接口名+Obj字符串的规则去定义服务类，乙方做DL时只需要配合runtime，也是轻而易举。

那么如果服务类实例化需要参数呢?

配置文件能解决这个问题，上文有提到Spring框架做DI的原理就是 反射+xml ，一般来说大部分支持反射机制语言的DI框架原理都是相似的，这里说下笔者了解的两种主流注入原理，构造器注入和属性注入，记得上文也提到过着两种注入方式，笔者强调过那只是一种思想，不是定性的一种方法，ok来看下那些DI框架是怎样做的。

• 构造器注入
  在进行依赖获取的时候，DI框架通过反射机制得到待创建类的构造方法，然后根据构造器所需参数的类型或者顺序，在DI容器节点中寻找，然后提供参数，创建实例。
• 属性注入
  同样的，在进行DL时，通过反射得到待创建类型的所有属性，然后根据属性在DI容器节点中进行匹配，有则创建提供，无则跳过。

最后利用词条做个局部总结：

• 依赖注入+接口编程
• 调用者无须关心对象任何实现，只需按照接口规则调用服务
• 在系统分析和架构中，分清层次和依赖关系，每个层次不是直接向其上层提供服务（即不是直接实例化在上层中），而是通过定义一组接口，仅向上层暴露其接口功能，上层对于下层仅仅是接口依赖，而不依赖具体类。
• 服务使用端由对对象的依赖转变成对接口的依赖，这样甚至可以在服务提供对象还未存在之前编码（分子项目开发）

End

依赖注入只是一种思想，其实也就是一个过程，依赖注入用到了面向接口的编程思想，面向接口的架构实现用到了依赖注入的执行方式。而面向接口编程和面向对象编程并不是平级的，它并不是比面向对象编程更先进的一种独立的编程思想，而是附属于面向对象思想体系，属于其中一部分。或者说，它是面向对象编程体系中的思想精髓之一。

同时我要赞叹POP的强大，对于未来的未知事物，我们先认知这个东西的行为(使用接口来实现这个行为)，再认知这种行为的具体(使用具体的代码实现这个接口)。

这篇文章中有提到广义的"接口"也有专指的"接口"，读后具体的理解和认识就靠自己用时间去慢慢沉淀了。

写在最后

在我对依赖注入理解得比较浅的时候，只是浅层地理解这种思想的存在，并没有相关开发经验足以支撑我深入对DI的思考和感受，网上的文章全部都仅仅局限在那几个浅层的例子，并没有继续深入挖掘解释，全靠一位师兄为我讲解，所以我希望有篇文章可以聚集大家思考讨论，同时为他人提供学习的途径。心中有疑惑又无能为力的感觉的确非常痛苦。谢谢！

参考资料

http://www.olinone.com/?p=429 https://www.objc.io/issues/15-testing/dependency-injection/ http://sharpfivesoftware.com/2013/03/20/dependency-injection-is-not-a-virtue-in-objective-c/ http://objection-framework.org/ http://www.myexception.cn/operating-system/1894403.html http://www.cnblogs.com/devinzhang/p/3862942.html