|
|
| 作者： 来源：BlogJava 发布时间：2006-03-14 00:00:00.0 | |
| 依赖注入（@H_502_30@Dependency Injection）模式的特点分析与实现 ――构造子注入（@H_502_30@Constructor Injection）模式的分析与实现 @H_502_30@ @H_502_30@ 蔡@H_502_30@ 超
超越巅峰 2006-03-14 08:52
（@H_502_30@chaocai2001@yahoo.com.cn） @H_502_30@ 摘要：本文对@H_502_30@IoC模式、依赖注入@H_502_30@(Dependency Injection) 模式做了简要介绍，文中分析构造子注入模式与其他模式相比较的优势和特点，并给出了在@H_502_30@JAVA中实现该模式的方法。 @H_502_30@ @H_502_30@ @H_502_30@1 引言@H_502_30@IoC（@H_502_30@Inversion of Control）模式以被目前的轻量级容器所广泛应用，通过@H_502_30@IoC模式这些容器帮助开发者将来自不同项目的组件装配成一个内聚的应用程序。轻量级的@H_502_30@IoC容器（如@H_502_30@Spring、@H_502_30@pico-container）虽然为我们的开发提供了很大的便利，但是在很多情况下这些轻量级容器所提供的功能并不一定非常适合我们的需要，也许这些容器的功能过于庞大了，或者所提供的功能缺乏对特定应用的针对性，或者我们需要更高的运行效率，这时我们可以在了解@H_502_30@IoC的原理的基础上利用@H_502_30@JAVA的反射机制自己实现灵活的、可扩展的组件机制。 @H_502_30@2 @H_502_30@IoC与依赖注入（@H_502_30@Dependency Injection）模式简介与@H_502_30@GoF的设计模式相同，@H_502_30@IoC模式同样是关注重用性，但与@H_502_30@GoF模式不同的是@H_502_30@IoC模式更加关注二进制级的重用性和可扩展性，即可以直接通过二进制级进行扩充，复用的模块通常被称为组件或者插件，组件和插件都是在运行时进行装载的。 @H_502_30@GoF的设计模式中我们大量看到的是面向接口编程：@H_502_30@Interface Driven Design 接口驱动，接口驱动有很多好处，可以提供不同灵活的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执行： @H_502_30@AInterface a = new AInterfaceImp(); 由于以上的代码被写入了调用者程序中，同时象@H_502_30@AinterfaceImp这样的接口的实现类是在编译时被装载的，如果以后想加入新的接口实现类则必须修改调用者的代码。 @H_502_30@IoC模式与以上情况不同，接口的实现类是在运行时被装载的，这样即使以后新添加了接口实现类是也不需修改调用者的代码（可以通过特定的方式来定位新增的实现类，如配置文件指定）。@H_502_30@IoC英文为@H_502_30@ Inversion of Control，即反转模式，这里有著名的好莱坞理论：你呆着别动，到时我会找你。 @H_502_30@IoC模式可以延缓接口的实现，根据需要实现，有个比喻：接口如同空的模型套，在必要时，需要向模型套注射石膏，这样才能成为一个模型实体，因此，对于这些新生的容器，它们反转的是“如何定位插件的具体实现”。因此， @H_502_30@Martin Fowler@H_502_30@ 给这种模式起了一个形象的名称“依赖注入”（@H_502_30@Dependency Injection）。 图表 @H_502_30@1 采用@H_502_30@Dependency Injection前后的依赖关系变化 依赖注入的形式主要有三种，分别将它们叫做构造子注入（@H_502_30@Constructor Injection）、设值方法注入（@H_502_30@Setter Injection）和接口注入（@H_502_30@Interface Injection）。 这三种方式在@H_502_30@Martin Fowler的《@H_502_30@Inversion of Control Containers and the Dependency Injection pattern》中都给出了详细的定义及说明，本文就不再赘述了，下面的内容将着重介绍构造子注入模式的特点及实现方法。 @H_502_30@3 构造子注入模式的特点及实现@H_502_30@3.1 构造子注入模式的特点通常情况下设值方法注入和接口注入较易于被开发人员接受，而构造子注入则应用较少，实际上构造子注入具有很多其他两者所不具有的优势： @H_502_30@1 构造子注入形成了一种更强的依赖契约 @H_502_30@3 更加简明的依赖声明机制，无须定义@H_502_30@XML配置文件或设值方法 @H_502_30@4 更加符合接口与实现分离的组件特征，组件接口表明能够向其它组件提供的服务，而实现则应该是所提供服务的实现应该与服务契约无关（即不应包含用于获得依赖的设值方法等）。 @H_502_30@5 不会出现不确定的状态。在设值方法注入中，由于并不是所有的设值方法（@H_502_30@setter）都一定会被调用的，所以会有不确定状态。 从以上几点我们还可以分析出构造子注入对于组件代码的入侵性远小于其它两种模式@H_502_30@(接口注入使得组件必须实现特定接口，设值方法同样要求组件提供特定的@H_502_30@setter方法@H_502_30@)，代码更加易于维护。@H_404_408@ 图表 @H_502_30@2 示例中类的关系 @H_502_30@Client的实现依赖于接口@H_502_30@A、@H_502_30@B和@H_502_30@C的实现，但是为了提供系统更好的灵活性和可扩展性，各接口的实现以组件的方式利用@H_502_30@java的反射机制进行运行时装载，注意到组件间可能会存在某种依赖关系，例如组件@H_502_30@AX依赖与接口@H_502_30@B的实现类，而这中依赖关系必须在运行时动态注入，组件为了告诉组件的调用者这种依赖关系以便注入，可以使用上文提到的各种模式： @H_502_30@1 使用接口注入模式 @H_502_30@public interface InjectB{ @H_502_30@ public void injectB(B bImp); @H_502_30@} @H_502_30@public interface InjectC{ @H_502_30@ public void injectC(C cImp); @H_502_30@} @H_502_30@public class AImp implements A,InjectB,InjectC{ @H_502_30@ … @H_502_30@ public void injectB(B bImp); @H_502_30@ public void injectC(C cImp); @H_502_30@ … @H_502_30@} @H_502_30@2 使用设值注入模式 @H_502_30@public class AImp implements A { @H_502_30@ … @H_502_30@ public void setB(B bImp); @H_502_30@ public void setC(C cImp); @H_502_30@ … @H_502_30@} @H_502_30@ @H_502_30@3 使用构造子注入模式 @H_502_30@public class AImp implements A { @H_502_30@ … @H_502_30@ public AImp(B bImp,C cImp){ @H_502_30@ … @H_502_30@ } @H_502_30@ … @H_502_30@} 由以上实例可以清楚的看出采用构造子注入模式的实现组件代码最为简单，且所受的入侵性最小。 @H_502_30@3.2 在@H_502_30@JAVA中实现构造子注入模式在@H_502_30@java及@H_502_30@.NET这样具有反射功能的语言中实现类型的运行时载入并不复杂，只要通过@H_502_30@Class.forName或生成自己的@H_502_30@ClassLoader就可以实现。 同样我们可以通过反射机制获取组件构造函数的参数，注入相应接口的实现，作者将此过程进行了封装，以下是代码： @H_502_30@public class RefectHelper { @H_502_30@ public Object ConstructorHelper(String className,ConstructorParamDeal pd) throws Exception{ @H_502_30@ try{ @H_502_30@Constructor[] constructs=Class.forName(className).getConstructors(); //实现中默认使用第一个构造函数类创建实例@H_502_30@ @H_502_30@ Class [] classes=constructs[0].getParameterTypes(); @H_502_30@ Object []obj=pd.dealParam(classes); @H_502_30@ //创建实例 @H_502_30@ return constructs[0].newInstance(obj); @H_502_30@ }catch(Exception e){ @H_502_30@ throw e; @H_502_30@ } @H_502_30@ @H_502_30@ @H_502_30@ } @H_502_30@} @H_502_30@/** @H_502_30@**/ @H_502_30@public interface ConstructorParamDeal { @H_502_30@ /** @H_502_30@ *根据构造函数中参数的类型注入@H_502_30@,相应的实现 @H_502_30@ @param classes 构造函数的参数类型 @H_502_30@ ◎@H_502_30@return 注入构造函数的参数实现 @H_502_30@ **/ @H_502_30@ public Object [] dealParam(Class [] classes); @H_502_30@} @H_502_30@public class ParamDeal implements ConstructorParamDeal{ @H_502_30@ @H_502_30@ /* (non-Javadoc) @H_502_30@ * @see com.topsec.tsm.agent.helper.ConstructorParamDeal#dealParam(java.lang.Class[]) @H_502_30@ */ @H_502_30@ public Object [] dealParam(Class[] classes) { @H_502_30@ Object [] obj=new Object[classes.length]; @H_502_30@ for (int i=0;i<obj.length;i++){ @H_502_30@ //为不同类型注入选择不同实例 @H_502_30@ if (classes[i].equals(String.class)){ @H_502_30@ obj[i]=”Hello World”; @H_502_30@ } @H_502_30@ } @H_502_30@ return obj; @H_502_30@ } @H_502_30@ @H_502_30@} 上面的程序中@H_502_30@ConstructorHelper用于利用反射机制枚举出载入类的构造函数及构造函数的参数的类型，至于不同类型注入什么样的实例则由@H_502_30@ContructorParamDeal的实现者来决定，@H_502_30@ContructorParamDeal的实现者同样可以以组件的形式在运行时动态载入。由于组件间的依赖关系的制约，所以组件实例化的顺序需要特别考虑。 @H_502_30@4 结束语三种依赖注入模式各有其特点和优势，只有充分理解这些模式间的不同，才能为自己的应用选择正确的依赖注入模式，文中介绍的构造子注入模式实现方法，在使用其他具有反射功能的语言（如：@H_502_30@.NET）时同样可以参考。 @H_502_30@ @H_502_30@ @H_502_30@ @H_502_30@1 @H_502_30@Martin Fowler,Inversion of Control Containers and the Dependency Injection pattern,http://www.martinfowler.com/articles/injection.html,2004 @H_502_30@2 Erich Gamma,Design Patterns,Addison Wesley,1999 @H_502_30@3 http://www.picocontainer.org/ @H_502_30@4 @H_502_30@彭晨阳,@H_502_30@Ioc模式@H_502_30@,@H_502_30@ http://www.jdon.com,2004 |
