2.1.1 IoC容器和依赖反转模式.docxVIP

第一部分Spring核心实现篇 第2章 Spring Framework的核心：IoC容器的实现 朝辞白帝彩云间，千里江陵一日还。 两岸猿声啼不住，轻舟已过万重山。 -【唐】李白《早发白帝城》 2.1? Spring IoC容器概述 2.1.1? IoC容器和依赖反转模式 子曰：温故而知新。在这里，我们先简要地回顾一下有关依赖反转的相关概念。我们选取维基百科中关于依赖反转的叙述，把这些文字作为我们理解依赖反转概念的参考。这里不会对这些原理进行学理上的考究，只是希望提供一些有用的信息，以便给读者一些启示。这个模式非常重要，它是IoC容器得到广泛应用的基础。 维基百科对依赖反转相关概念的叙述 早在2004年，Martin Fowler就提出了哪些方面的控制被反转了？这个问题。他得出的结论是：依赖对象的获得被反转了。基于这个结论，他为控制反转创造了一个更好的名字：依赖注入。许多非凡的应用（比HelloWorld.java更加优美、更加复杂）都是由两个或多个类通过彼此的合作来实现业务逻辑，这使得每个对象都需要与其合作的对象（也就是它所依赖的对象）的引用。如果这个获取过程要靠自身实现，那么如你所见，这将导致代码高度耦合并且难以测试。 以上的这段话概括了依赖反转的要义，如果合作对象的引用或依赖关系的管理要由具体对象来完成，会导致代码的高度耦合和可测试性降低，这对复杂的面向对象系统的设计是非常不利的。在面向对象系统中，对象封装了数据和对数据的处理，对象的依赖关系常常体现在对数据和方法的依赖上。这些依赖关系可以通过把对象的依赖注入交给框架或IoC容器来完成，这种从具体对象手中交出控制的做法是非常有价值的，它可以在解耦代码的同时提高代码的可测试性。极限编程中对单元测试和重构等实践的强调体现了软件开发过程中对质量的承诺，这是软件项目成功的一个重要因素。 依赖控制反转的实现方式有很多种。在Spring中，IoC容器是实现这个模式的载体，它可以在对象生成或初始化时直接将数据注入到对象中，也可以通过将对象引用注入到对象数据域中的方式来注入对方法调用的依赖。这种依赖注入是可以递归的，对象被逐层注入。就此而言，这种方案有一种完整而简洁的美感，它把对象的依赖关系有序地建立起来，简化了对象依赖关系的管理，在很大程度上简化了面向对象系统的复杂性。 本篇将对Spring的核心IoC容器和AOP的实现原理进行阐述。IoC容器和AOP是Spring的核心，是Spring系统中其他组件模块和应用开发的基础。从两个核心模块的设计和实现上可以了解到Spring倡导的对企业应用开发所应秉持的思路，比如使用POJO开发企业应用、提供一致的编程模型、强调对接口编程等。对于这些Spring背后的开发思想和设计理念，大家都不会陌生，在Rod Johnson的经典著作里都有全面和深刻的讲解。作为参考，我们可以看到Spring官方网站对Spring项目的描述。如下图所示，Spring的目标和愿景写得很清楚。 ?首先，Spring的目标在于让Java EE的开发变得更容易，这也就意味着Spring框架的使用也应该是容易的。对于开发人员而言，易用性是第一位的。为什么要让Java EE开发变得更容易，难道以前的Java EE开发很艰难？Spring究竟是如何让Java EE的开发变得更容易的呢？了解Java EE开发历史的读者都知道，正如Rod Johnson在他的著作Expert One-on-One Java EE Design and Development中提到的那样，EJB模型为Java EE开发引入了过度的复杂性，这个开发模型对Java EE的开发并不友好。有没有更好的开发模型呢？有，就是POJO！它让Java洗净铅华，恢复其自然的风采。使用POJO不仅能开发复杂的Java企业应用，而且还可以让Java EE开发在开发成本、开发周期、可维护性和性能上获得更大优势。对一般的企业应用需求而言，重要的是如何方便地使用应用需要的服务，而不是各种各样的开发模型和模式。虽然这些模式为我们描绘了设计高可靠性分布式应用的美妙场景，但这些场景是不是大多数企业应用开发者所要面对的呢？ 世上都说Java好，唯有Spring忘不了。喜欢Java，是因为它简洁，不但包含了面向对象的语言特性，同时还可以跨平台，可谓是简洁而又强大。但是，进入到企业应用后，作为门外汉的自己一看到复杂的EJB模型就心生畏惧。这时候，我接触到了Spring，她给人的第一印象就是简洁却又具有丰富的内涵，就像第一次遇到Java一样，被她的这种特质深深地吸引了。她降低了企业应用开发的门槛，还原了POJO的本色，让我们直接依赖于Java语言，直接依赖于面向对象编程，使用无所不在的单元测试来保证代码质量，这样我们就有信心能够开发出高质