摘要：文章详细分析了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）的底层都是采用这种技术。
 
    二、依赖注入的几种形式
 
 &nbs