对依赖注入技术的初学指导.docVIP

　　对依赖注入技术的初学指导～教育资源库 　　序：依赖注入技术(Dependency Injection)被世人所认知和使用有一段时间了。近来，越来越多的人开始使用它的原理来设计、开发、和单元测试Java程序。一些很优秀很有意思的开源框架也由此开发出来，比如SpringFramework和Google Guice等等。译者翻译的这篇近两年前的文章，对于人们了解和学习Dependency Injection的基本原理应该是有裨益的。 　　就Dependency Injection目前在业界的直译（依赖注入）而言，译者认为不明了。所以以下就还一直使用英文。另请注意，这项技术并不是将依赖性进行注入，而是一些功能和资源的注入，请读者不要望文生义。 　　原文： 　　范畴 　　这篇文章从较高的层次来一览Dependency Injection（DI）技术。它的目的是在如何使用几种DI容器的背景下，把DI技术概念性地介绍给初学者。 　　是DI还是IOC（反向控制）？ 　　当前的许多资料通常将DI和IOC混为一谈。就我个人而言，DI应该是一个更具体的名字。我能想像在许多情况下使用IOC的时候，不见得最后的模式就是以解决依赖性为重心（比如从一个控制台应用程序到一个窗口事件循环）。但是，如果你更习惯IOC，你基本上可以将以下文章里的DI换成IOC来读。IOC有多种类别，像一类，二类，三类。这些类别间的不同不 　　在本文的讨论范围之内。 　　另请注意我在本文里大量使用了服务端(Service)词。请不要将它混淆为以服务为导向的框架（SOA）。我这里的意思只是用用户端来代表用户端组件，服务端来代表服务端组件。 　　DI的简要介绍 　　简要介绍 　　情境一 　　假设你在一个将出差当成家常便饭的公司工作。通常来说，你乘飞机来旅行。每次你赶飞机时，总是要安排taxi。你认识航空公司订票的人员，出租车公司安排taxi送你到机场的人员。你知道他们的，你知道通常订票的谈话内容。你的典型的旅行步骤如： 　　决定目的地，和希望到达时间； 　　给航空公司打，将必要的旅行信息传达出去，用以订票 　　给出租公司打，要求taxi从你住地送你到机场去赶某一具体航班（出租公司可能需要联络航空公司来得到航班的起飞时间表，机场信息，并计算从你住地至机场的的具体时间，及相应的到达你住地的时间） 　　获取机票，赶上taxi，开始出差之旅 　　如果现在你的公司突然更换原先订票的经纪以及相应的交流手段，你可能被迫进入重新熟悉的境地： 　　新的经纪公司，他们的交流方式（比如说，如果新的经纪通过互联网来做生意，而不是原来的） 　　用以成交的典型的谈话方式的次序（是数据，而不再是声音） 　　不仅仅是你，很可能你的许多同事也要对此变化进行适应。适应的过程往往要花上可观的时间。 　　情境二 　　现在让我们来假设整个程序有一点点不同。你们公司有一个行政部门。当你需要出差旅行的时候，行政部门的互动系统会给你打（事实上是将你和订票经纪公司挂起钩来）。在上，你只需回答特定的一套问题，来讲出你的目的地和需要的到达时间。机票订票系统是专为你们设计的，出租公司将计划好taxi的时间，同时，机票也会给你送上门来。 　　如果现在订票的经纪更换了的话，行政部门会知会这个变更，也许他们会相应调整订票经纪的工作流程。互动的系统可以重新程序化，以便于和经纪在互联网上沟通。但是，你和你的同事们不需要有任何的重新适应过程。你仍旧只需照先前的程序走就行了（所有的调整都由行政部门去做了） 　　依赖注入（Dependency Injection） 　　在上述两个情境中，你是客户，你依赖于经纪提供的服务。但是，情境二有些不同： 　　你不需要知道订票经纪人和 － 必要的话，公司行政部门会打给你 　　你不需要知道行政部门和订票经纪的交流程序和方式，虽然你知道如何与行政部门一个特定的交流方式 　　你不需要作出任何调整，即使当给你提供服务的经纪有变更的时候 　　这就是现实生活中的依赖性注入（DI）。这种方式看上去省不了你什么，但是当你把它应用到一个大公司里去时，他的节省是很可观的。 　　在软件领域里的DI 　　软件的组件（用户端）通常是一整套相互作用的组件中的一部分，这一整套组件又会依赖于一些其他的组件（服务端）来完成它们的预定目标。在许多情况下，它们需要知道和哪些组件打交道，在哪里可以找到那些组件，以及如何和那些组件交流。如果获取到这些组件（服务端）的方式改变时，这些变化可能迫使大量用户端的组件作出调整。 　　有鉴于此，把代码结构化的一个方法是，将找到和实例化服务端组件的逻辑嵌入到用户端的组件里。另一个方法是将客户端对服务端的依赖性声明，让一些外在