IoC原理浅析
|
来源：网友投稿
摘要：文章详细分析了IoC设计模式的原理，讨论了依赖注入的3种方式并对每种方式特点进行了阐述和对比，最后说明了IoC实际作用。
关键词：控制反转；依赖注入
在一个典型的软件系统中，必定要把整个系统划分为若干个模块，大多数开发者难以理解和把握过于复杂的系统。把软件系统划分成多个模块，可以有效控制模块的复杂度，使每个模块都易于理解和维护。但在这种情况下，模块之间就必须以某种方式交换信息，也就是必然要发生某种耦合关系。
因此，模块之间必定会有这样或那样的依赖关系，过强的耦合关系（如一个模块的变化会造成一个或多个其他模块也同时发生变化的依赖关系）会对软件系统的质量造成很大的危害。特别是当需求发生变化时，代码的维护成本将非常高。所以，必须控制和消解不必要的藕合，特别是那种会导致其它模块发生不可控变化的依赖关系。IoC、DI（依赖注入）等方法就是开发者仔细研究依赖关系，经过许多设计实践后发展起来的新方法。
一、IoC原理
在传统的模块实现中，由程序代码直接控制程序之间的关系。而加入了IoC设计概念后，意味着将你设计好的类交给系统去组装控制，而不是在你的类内部控制，这称为控制反转（Inversion of Control，IoC）。对于框架而言就是由容器控制程序之间的关系，而非传统实现中由程序代码直接操控。这就是“控制反转”的概念的本意，即控制权由应用代码中转到了外部容器，控制权发生了转移所以称为反转。
IoC框架就是将对象的创建和获取提取转移到外部容器，由外部容器提供需要的组件。对于Spring这样的轻量级容器，它们的反转是“如何定位插件的具体实现”。这里的“插件”就是实现具体业务逻辑的组件，它是在程序的运行期间而不是编译期间插入到应用程序当中去的。只要插件遵循一定的规则，一个独立的组装模块就能够将插件的具体实现“Injection”到应用程序中，把这种做法的模式叫做“依赖注入（Dependency Injection，DI）”。依赖注入就是将组件间的依赖关系提取到组件的外部，由容器来实现依赖关系的注入，从这方面讲，这里将实现控制反转（IoC）与依赖注入框架认为是同等的。
实现IoC完成依赖注入的关键技术是“反射机制”。Java语言产生的最根本的目的是为了适应网络应用。Java语言中的反射机制的制定与实施，其本意是为了能够在网络中传递对象，并能够根据所传递的对象信息，重构对象本身，所以这种重构是动态的。反射机制对于RPC和RMI（远程过程和远程方法调用）功能的实现起到了巨大的作用。在Java语言中，一个类具有的各个属性和方法，通过其它相关的类用以实现对其信息的提取和重构，这些类都集中在java.lang.reflect包中，如Field类提供了动态操作一个类或接口中的某个属性的信息，并且这种属性既可能是某个类的属性，也可能是某个类实例的属性。Method提供了操作某个类或实例的方法的信息。
Java反射机制的根源是Java中所有类的共同继承的父类Class类，此类的实例代表了应用程序中的某个类或接口，在编译Java类的时候，关于Class类的相关信息就写入编译的类中。Class提供了动态装载某个类的能力，而这种装载过程依赖于两个因素：JVM（Java虚拟机）和在编译过程中附加于某个类上的信息。如果有Class动态装载某个类，JVM就首先到内存中寻找这个类，如没有找到，则按照系统所设定的classpath到外存上去寻找此类，并执行相应的加载。Class提供了动态提取内存中相应类的各种元素的方法。若想得到某个类的所有Fields，可以使用“类实例.getClass（）”，得到此类的Class对象，然后利用Class对象的getFields方法得到这个类的所有公有属性。所有属性构成了Field域。Field方法提供的getName（）方法可以得到通过“字段名.get（类实例）”得到此字段的值。而Class提供的方法getName）则能够得到某个字段合原始数据类型的名称，如果字段属于某个类，则得到类的名字。如此周而复始，可以追踪所有的相关联的类的字段。
使用反射机制，可以让容器在编译时并不关注具体的功能，具体的功能可以通过配置在运行时动态的得到，这样就可以十分灵活地增加需求。但与此同时系统的性能受到了影响，为了系统的可维护性和可扩展性，做出这种取舍是非常适当的。目前许多容器（如Spring和Hibernate）的底层都是采用这种技术。
二、依赖注入的几种形式
（一）接口注入
接口注入其核心思想是借助接口来将调用者与实现者分离。如下面的代码所示：
public class A{
private InterfaceB cB;
public someMothod(){
Ojbect obj =Class.forName(“接口InterfaceB的实现类”).newInstance();
cB=(InterfaceB)obj;
}
类A依赖于InterfaceB的实现，在编译期间A只依赖于InterfaceB，在运行时根据预先在配置文件中设定的实现类的类名动态加载实现类，并通过InterfaceB强制转型后为类A所用，实现了调用者与实现者在编译期分离。Typel型IoC容器加载接口实现并创建其实例的工作由容器完成，如J2EE开发中常用的Context.lookup（ServletContext.getXXX）。
（二）设值方法注入
设值注入方式就是通过JavaBean构件模型中的setter方法传入被调用者的实例，IoC容器通常通过XML文件中的配置信息完成组件的配置。设值注入模式是Spring鼓励采用的方式，在实际开发中得到了最广泛的应用。相应的实现代码如下：
public class DIBySetter{
private DataSowce dataSource;
public DIBySettern(){}
public void setDataSource(DataSowce ds){this.dataSource=ds; }
}
（三）构造子注入
构造子注入是通过类的构造函数来完成依赖关系的设定，一个著名的轻量级容器PicoContainer就是利用这种方法完成依赖注入的。如下面的代码示：
public class DIByConstructor{
private final DataSource dataSource;
private final String message;
public DIByConstructor(DataSource ds, String msg){
this.dataSource=ds;
this.message=msg;
}
可以看到，在Type3类型的依赖注入机制中，依赖关系是通过类构造函数建立，容器通过调用类的构造方法，将其所需的依赖关系注入其中。
三、依赖注入方法的比较
由于接口注入模式要求组件必须与特定的接口相关联，因此并不被看好，实际使用有限。
设值注入和构造子的依赖注入实现模式均具备无侵入性的特点，所谓的“无侵入性”就是代码中不需要涉及框架的专有类，即可将其被框架容器进行管理。
设值注入的优点：setter方法设定的依赖关系与JavaBean的setter设值方法比较相近，对于用惯了JavaBean的开发者来说比较自然；设值注入的方法比较直观简洁；与第三方类库的冲突可能性减小。
构造子注入方法的优点有：“在构造期即创建一个完整、合法的对象”，对于这条Java设计原则，构造子注入方法无疑是这条原则的典型样板。由于没有setter方法，依赖关系在构造时由容器一次性设定，因此组件在被创建之后即处于相对“不变”的稳定状态，无需担心上层代码在调用过程中执行setter方法对组件依赖关系产生破坏。由于关联关系仅在构造函数中表达，只有组件创建者需要关心组件内部的依赖关系。对调用者而言，组件中的依赖关系处于黑盒之中。对上层屏蔽不必要的信息，也为系统的层次清晰性提供了保证。可见设值注入和构造子注入各有优势，理论上应以构造子注入为主，值注入为辅，可以达到比较好的注入效果。但在基于Spring框架开发的系统中，大都采用值注入方法。使用Ioc模式与框架可提供种新的机制管理业务对象及其依赖关系，可以降低代码耦合，使依赖外置化，可以在统一的地方管理依赖，从而有效地降低软件开发问题的复杂度、减小维护的代价。
参考文献：
1、Gulzar N, Kartik. Practical J2EE Application architecture[M].The McGraw-Hill Companies,2003.
2、罗时飞.精通Spring2.0[M].电子工业出版社,2007.
（作者单位：东北林业大学信息与计算机工程学院。其中，王霓虹为教授、博士生导师、院长）