Guice了解理解及应用

首先，从dependency injection理解开始，咱不叫依赖注入，因为意译的和其实含义不太一样。后面都统一叫“DI”。一个小故事：
情境一
假设你在一个将出差当成家常便饭的公司工作。通常来说，你乘飞机来旅行。每次你赶飞机时，总是要安排taxi。你认识航空公司订票的人员，出租车公司安排taxi送你到机场的人员。你知道他们的电话，你知道通常订票的谈话内容。你的典型的旅行步骤如：

    * 决定目的地，和希望到达时间；
    * 给航空公司打电话，将必要的旅行信息传达出去，用以订票
    * 给出租公司打电话，要求taxi从你住地送你到机场去赶某一具体航班（出租公司可能需要联络航空公司来得到航班的起飞时间表，机场信息，并计算从你住地至机场的的具体时间，及相应的到达你住地的时间）
    * 获取机票，赶上taxi，开始出差之旅

如果现在你的公司突然更换原先订票的经纪以及相应的交流手段，你可能被迫进入重新熟悉的境地：

    * 新的经纪公司，他们的交流方式（比如说，如果新的经纪通过互联网来做生意，而不是原来的电话）
    * 用以成交的典型的谈话方式的次序（是数据，而不再是声音）

不仅仅是你，很可能你的许多同事也要对此变化进行适应。适应的过程往往要花上可观的时间。

情境二
现在让我们来假设整个程序有一点点不同。你们公司有一个行政部门。当你需要出差旅行的时候，行政部门的互动电话系统会给你打电话（事实上是将你和订票经纪公司挂起钩来）。在电话上，你只需回答特定的一套问题，来讲出你的目的地和需要的到达时间。机票订票系统是专为你们设计的，出租公司将计划好taxi的时间，同时，机票也会给你送上门来。

如果现在订票的经纪更换了的话，行政部门会知会这个变更，也许他们会相应调整订票经纪的工作流程。互动的电话系统可以重新程序化，以便于和经纪在互联网上沟通。但是，你和你的同事们不需要有任何的重新适应过程。你仍旧只需照先前的程序走就行了（所有的调整都由行政部门去做了）

依赖注入（Dependency Injection）

在上述两个情境中，你是客户，你依赖于经纪提供的服务。但是，情境二有些不同：

    * 你不需要知道订票经纪人和电话 － 必要的话，公司行政部门会打电话给你
    * 你不需要知道行政部门和订票经纪的交流程序和方式，虽然你知道如何与行政部门一个特定的交流方式
    * 你不需要作出任何调整，即使当给你提供服务的经纪有变更的时候

这就是现实生活中的依赖性注入（DI）。这种方式看上去省不了你什么，但是当你把它应用到一个大公司里去时，他的节省是很可观的。

    这是生活中的一个例子，可能会比较直观。在程序中由于DI多要定义interface,所以总结起来理解三句话就明白了DI是什么了：1、好莱坞理论：你别动，我回来找你！2、把服务之间的这种依赖的建立时间推后了，从编译器推迟到运行时；3、接口就是一个模具，要什么样的成品你就灌什么样的浆。










使用DI能得到什么？

对DI从整体来看，无论是作为一个设计模式，还是不同的框架，你可能都会问，我能从DI上得到些什么？以下就是一些好处

    * 如果审视你的服务组件依赖性，它会包含两个子依赖性。一个是基于API或服务组件自身协议的专于某一领域的依赖性。另一个是泛指基于服务组件间实例、配置、和查询的技术协议上的依赖性。DI允许你将处理后者的代码转移到附带的代码边界上去（如XML文件或一些离你的’主‘方法不远的方法里）。这样，一些技术上的更改得以较容易地处理，因为客户端组件的开发人员可以集中精力于他们最拿手的－服务端某一特定领域的API。
    * 如果你想创建即插即用的结构，从而你的最终用户和系统集成人员可能会要求延伸或更改服务端的功能，那么你用DI的方法来做会让事情变得很容易。DI让按开闭原理来建造软件变得容易。在举例中，我提到作为一个DI容器的Spring，其实Spring本身也大量地使用了DI。建造进Spring的一系列功能（如 AOP，交易处理等）实际上是用DI来插入这些即插即用的服务的。Spring框架也可以靠写一些额外的服务并用DI来插入它们得以延伸和拓展(比如说，spring模块，参见http://springmodules.dev.java.net）。
    * 如果你真的在应用中，建立大量的细分的彼此间相互依赖的服务，很可能你要重新布局的次数，比你预计的要来的多。如果你真的用了DI的框架的话，你会很庆幸你当初的选择。
    * 当你最初的假设开始变更的时候，你需要开始加强你的应用。比如，你有建在J2EE平台上的服务组件，它们之间靠JNDI来相互查询。如果你现在把代码移植到一个没有JNDI的环境中去，如果你当初用了DI的话，就没有一点问题。

待续。。。