伴随着轻量级容器(Spring和PicoContainer等)的出现,Inversion of control(反转控制)和Dependency Injection(依赖注射)模式开始流行起来。
实际上,Inversion of control 是所有Frameworks框架最基本的特性之一,“反转控制“不是什么新的内容。比如程序流程控制权的反转,控制权由程序本身转移到Framework手中。在FrameWork框架中一般会采用Template Method模式来实现控制权的反转。
而新的轻量级IoC容器提出的Inversion of control实际上“反转的是如何定位组件”,我们可以把这里的组件理解为一些类,就是说如何去获得我所需要的类。
在Ioc容器之前,这个工作由我们自己在程序中实现(比如通过new、工厂类、或者Service Locator模式)。而现在IoC容器可以为我们去实现这一点。IoC容器解决的就是如何把我们所需要的类的Instance注射到我们的应用中。
Martin Fowler认为Inversion of control太泛泛了,并不能有效地描述新的Ioc Container的特点。所以他提出了一个新的名词:依赖注射( Dependency Injection),就是在程序运行的时候,将某个类所依赖的组件注射到该类中。
依赖注入的形式主要有三种,分别称为构造子注入(Constructor Injection)、设值方法注入(Setter Injection)和接口注入(Interface Injection)。
搞清楚下面关系,有助于我们理解“依赖注射”。
(1)IoC容器(依赖注射)和OO设计的关系。
OO设计强调对接口进行编程,但是我们程序中必然要涉及到接口的Instance。IoC容器就是解决如何把所依赖的Instance注射到我们的应用程序中。
(2)依赖注射和Service Locator的关系
消除应用程序和组件之间依赖的方法有两种:一种是依赖注射,另一种是采用Service Locator模式。
两者的主要区别是:
使用Service Locator模式,需要应用程序显示式地调用Service Locator,向它请求所需要的服务。
使用Dependency Injection模式,应用程序不用发出显式的请求,服务的实现自然会出现在应用程序代码中。
使用Service Locator 模式时,服务的使用者必须依赖于Service Locator。Service Locator可以隐藏使用者对服务具体实现的依赖,但你必须首先看到服务定位器本身。所以,选择Service Locator 还是Dependency Injection,取决于“对服务定位器的依赖”是否会给你带来麻烦。
阅读(405) | 评论(0) | 转发(0) |