Question

前言： Spring 这个轻量级的框架已经成为 Web 开发事实上的标准， 不少同学建议我写一些 Spring 相关的技术， 我刚开始是拒绝的， 因为现在网上相关的文章是在太多了。

后来想想，这些文章更多的关注细节和实现，教大家怎么用， 关注 how , 真正讲解 why 的还不多， 我觉得我可以给大家分享下 我对 Spring 本质的感想和体会 ，这就是这篇文章的由来， 如果大家喜欢，就继续的写下去。

希望你对 OO,设计模式，单元测试，XML，反射等技术有一定了解， 不了解也没关系，直接看下去就是了 :-) 1 对象的创建 面向对象的编程语言是用类(Class) 来对现实世界进行抽象， 在运行时这些类会生成对象(Object)。

当然，单独的一个或几个对象根本没办法完成复杂的业务， 实际的系统是由千千万万个对象组成的， 这些对象需要互相协作才能干活，例如对象 A 调用对象 B 的方法，那必然会提出一个问题：对象 A 怎么才能获得对象 B 的引用呢？

最简单的办法无非是： 当对象 A 需要使用对象 B 的时候， 把它给 new 出来 ，这也是最常用的办法， java 不就是这么做的？例如：

Apple a = new Apple();

后来业务变复杂了， 抽象出了一个水果(Fruit) 的类， 创建对象会变成这个样子：

Fruit f1 = new Apple(); Fruit f2 = new Banana(); Fruit f3 = ......

很自然的，类似下面的代码就会出现： 这样的代码如果散落在各处，维护起来将会痛苦不堪， 例如你新加一个水果的类型 Orange, 那得找到系统中所有的这些创建 Fruit 的地方，进行修改， 这绝对是一场噩梦。 解决办法也很简单， 前辈们早就总结好了：工厂模式

（注：点击图片看大图）

看起来也没什么难度， 需要注意的是很多类一起协作了， 尤其是 OrderProcessor , 它依赖于 OrderService 和 EmailService 这两个服务，它获取依赖的方式就是通过 单例方法 。

如果你想对这个 process 方法进行单元测试-- 这也是很多优秀的团队要求的 -- 麻烦就来了。

首先 OrderService 确实会从真正的数据库中取得 Order 信息，你需要确保数据库中有数据， 数据库连接没问题，实际上如果数据库连接 Container（例如 Tomcat）管理的， 你没有 Tomcat 很难建立数据库连接。

其次这个 EmailService 真的会对外发邮件， 你可不想对真正的用户发测试邮件，当然你可以修改数据库，把邮件地址改成假的，但那样很麻烦， 并且 EmailService 会抛出一堆错误来，很不爽。

所有的这些障碍， 最终会导致脆弱的单元测试： 速度慢， 不可重复，需要手工干预，不能独立运行。

想克服这些障碍， 一个可行的办法就是不在方法中直接调用 OrderService 和 EmailService 的 getInstance() 方法， 而是把他们通过 setter 方法传进来。 通过这种方式，你的单元测试就可以构造一个假的 OrderService 和假的 EmailService 了。

例如 OrderService 的冒牌货可以是 MockOrderService , 它可以返回你想要的任何 Order 对象， 而不是从数据库取。

MockEmailService 也不会真的发邮件， 而是把代码中试图发的邮件保存下来， 测试程序可以检查是否正确。

你的测试代码可能是这样的： (点击图片看大图) 友情提示：我们熟悉的 bean 又出现了， 想了解历史的可以看下文章《Java 帝国之 Java bean (上) 》 和《Java 帝国之 Java bean (下) 》

这个 xml 挺容易理解的， 但是仅仅有它还不够， 还缺一个解析器（假设叫做 XmlAppContext）来解析，处理这个文件，基本过程是： 0. 解析 xml, 获取各种元素

1. 通过 Java 反射 把各个 bean 的实例创建起来： com.coderising.OrderProcessor , OrderServiceImpl, EmailServiceImpl.

2. 还是通过 Java 反射 调用 OrderProcessor 的两个方法：setOrderService(....) 和 setEmailService(...) 把 orderService , emailService 实例 注入进去。

应用程序使用起来就简单了：

XmlAppContext ctx = new XmlAppContext("c:\\bean.xml");

OrderProcessor op = (OrderProcessor) ctx.getBean("order-processor");

op.process();

其实 Spring 的处理方式和上面说的非常类似， 当然 Spring 处理了更多的细节，例如不仅仅是 setter 方法注入， 还可以构造函数注入，init 方法， destroy 方法等等， 基本思想是一致的。 既然对象的创建过程和装配过程都是 Spring 做的， 那 Spring 在这个过程中就可以玩很多把戏了， 比如对你的业务类做点字节码级别的增强， 搞点 AOP 什么的， 这都不在话下了。 4 IoC vs DI “不要给我们打电话，我们会打给你的(don‘t call us, we‘ll call you)”这是著名的好莱坞原则。

在好莱坞，把简历递交给演艺公司后就只有回家等待。由演艺公司对整个娱乐项目完全控制，演员只能被动式的接受公司的差使，在需要的环节中，完成自己的演出。

这和软件开发有一定的相似性， 演员们就像一个个 Java Object, 最早的时候自己去创建自己所依赖的对象， 有了演艺公司（Spring 容器）的介入，所有的依赖关系都是演艺公司搞定的， 于是控制就翻转了 Inversion of Control, 简称 IoC。

但是 IoC 这个词不能让人更加直观和清晰的理解背后所代表的含义， 于是 Martin Flower 先生就创造了一个新词 : 依赖注入 (Dependency Injection，简称 DI), 是不是更加贴切一点？