领导让我写一篇关于依赖注入的教案，正好一直也有想将近年来自己的所学所悟整理出来的想法，就在这里一边写着一边与大家分享吧～

一、入门：依赖注入

作为一种全新的设计模式理念，“依赖注入”这个词汇在软件设计开发中已经是越来越耳熟能详了，而各种流行于开源社区的“依赖注入框架”，也越来越多的被当作软件工程开发过程中使用的基础框架。这一章我们主要介绍什么是依赖注入、它的来源是什么、以及能给我们带来什么样的好处。

1.“依赖”的概念

要了解依赖注入，我们首先需要了解什么是“依赖”。从现实世界的观点来看，“依赖”即某个实体对象为了完成某项功能，必须要依托另外一些实体对象，那么这些被依托的实体对象即被称为“依赖”（Dependency），而依托其它“依赖”从而完成某项功能的对象，往往被称作“依赖者”（Dependent）。看似有些晦涩难懂，但用我们平常使用的Java语言来讲，其实很简单，所谓“依赖”，用最浅显的话说，就是我们平常写一个Java类中所定义的成员变量。（注：严格来说，还有把方法参数作为“依赖”的情况，我们暂不讨论此例）

看一个很常见的场景的例子：某储户需要到银行去办理一笔取款业务。在这个场景中，该储户即为一个“依赖者”；那么其为了完成取款业务，则需要依托很多其它的实体对象，为简单起见，我们假设该储户仅需要一张存折和附近的一所银行，此处存折和银行则为“依赖”。翻译成Java语言去描述，则可写出如下的代码。

2.传统的组件耦合方式及其带来的问题

我们都知道，一个对象（依赖者）当中调用另外一个对象（依赖）的API，即组件间的耦合是面向对象语言开发过程中必然要遇到的问题。拿我们刚才的例子来说，储户类调用银行类就可以看作是储户与银行两个组件在相互耦合。但是刚才的那个例子是不能被主程序直接运行的，因为我们的bank依赖并没有被初始化，所以如果调用到了Depositor#withDraw则会出现NullPointerException（NPE）异常。

因此我们需要想办法得到一个“组装”好的Depositor类的对象。在依赖注入设计模式出现以前，通常有下面几种组件的组装方法，我们依次来讨论一下。

2.1.手工组装模式

一种常见的组件耦合方式就是我们经常使用的“new”，即通过依赖类的构造方法new出一个新的对象作为依赖者类的初始化状态。

继续我们刚才的例子，在主程序能够new出依赖之前，首先我们要实现一个工商银行的银行类，以及一个工商银行的存折类。

之后我们便可以在Depositor类中利用这些实现类初始化出需要的依赖对象后，刚才的DepositMain就可以正常运行了。

这种手工new的组装方式，虽然是Java平台程序开发中最基本的方式，但是其会带给我们在开发、维护以及测试等方面带来极大的困扰。

l还以刚才的取款场景为例，开发过程中，对于实现储户取款这个场景（Depositor）的开发者来说，需要关心的事情只是储户取了多少钱，而不应该为了调用取款的API而费尽心思地去创建Bank和DepositBook对象。我们这个例子是非常简单的，仅仅是为了说明方便所以将依赖的构造函数的参数设定为及其简单的Java基础类型，试想在现实的开发中，Bank和DepositBook依赖自身还将会有依赖，依赖中又有依赖，如果是这样一个极其复杂的依赖关系图（DependencyGraph），对于开发人员来讲构建组件将会是非常痛苦的一件事情！并且，如果在依赖关系图中的某一层中涉及到了诸如DataSource连接、硬件连接这样的依赖对象，开发人员一定会抱怨“这些对象与我在开发的功能完全没有关系”！

l从代码维护的角度看，过多的用构造方法new出对象这种方式，对于代码变更的维护的成本也是巨大的。例如，我们的BankICBC实现类的构造参数发生了变更，比如需要追加一个“网点类型（分理处/支行/分行）”这样的参数，那么我们的代码中所有调用到BankICBC的地方都需要发生相应的修改及对应的回归测试！

l最后我们谈到的一点，也是软件开发过程中极其关键的一点，即给单元测试带来的不便。例如在实际的单元测试过程中，“工商银行”类由于牵扯到实际环境以及难以构建复杂依赖图等原因我们没有办法直接使用，而想要自行在测试代码中实现一个Mock类来代替实际的“工商银行”类，比如MockBank，我们会发现这个MockBank类没有办法方便地替入到实际的Depositor#withDraw代码中去。单元测试往往是软件工程中自动化程度最高，回归测试成本最低的测试手段，如果没有良好的单元测试体系，软件工程的维护等是难以方便的运行的。