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

核心提示： 你不需要知道行政部门和订票经纪的交流程序和方式，虽然你知道如何与行政部门一个特定的交流方式 你不需要作出任何调整，对依赖注入技术的初学指导(3)，即使当给你提供服务的经纪有变更的时候 这就是现实生活中的依赖性注入（DI），这种方式看上去省不了你什么，部分的服务端组件需要晓得其内部各组件之间

你不需要知道行政部门和订票经纪的交流程序和方式，虽然你知道如何与行政部门一个特定的交流方式

你不需要作出任何调整，即使当给你提供服务的经纪有变更的时候

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

在软件领域里的DI

软件的组件（用户端）通常是一整套相互作用的组件中的一部分，这一整套组件又会依赖于一些其他的组件（服务端）来完成它们的预定目标。在许多情况下，它们需要知道和哪些组件打交道，在哪里可以找到那些组件，以及如何和那些组件交流。如果获取到这些组件（服务端）的方式改变时，这些变化可能迫使大量用户端的组件作出调整。

有鉴于此，把代码结构化的一个方法是，将找到和实例化服务端组件的逻辑嵌入到用户端的组件里。另一个方法是将客户端对服务端的依赖性声明，让一些‘外在’的代码来承担找到和实例化服务端组件的任务，并提供相关的服务端的引用（reference）给客户端。后一种方式里，当寻找外在依赖性的方式变更时，客户端的代码通常不需要调整。这种实施的方法被认为是DI，前面提到过的那些’外在‘的代码可能是自己亲自写的，也可能是按一些现成的DI框架来实施的。

那些试着将上述情况在设计术语中得到印证的人会发现他们之间的可比性适用于三个不同的术语 － DI，工厂（Factory），和程序接口（不是具体的实施）。在这个比较中，这三个术语通常被用到（不一定同时用到）。

一直到几年前，传统的方法总是将接口和实施分离开来。工厂设计模式甚至允许将复杂的实例化隐藏起来。但是，找到服务端组件的机制就交给客户端去做了。而且，部分的服务端组件需要晓得其内部各组件之间的依赖关系，在实例化的过程中暗含的次序问题，以及跟踪和管理他们的生命周期。