IOC原理分析

 

IOC(inversion of control)控制反转

在我们的程序中，要实现某个功能，我们都会用到两个或两个以上的类来协同完成，那么在一个类中，我们就会要有它的合作类的引用，也就是说这个类依赖于别的类，这个合作类的获取，将会有一下几种不同的情况

依赖获取的三种方式： 

 

情况1.自己生成 

Class person{

   Eat(){

  Apple a=new Apple();

}

}

 

第一种方式：在person的eat()方法里就把吃的水果写死，从开始就创建对象，

      缺点 ：1.Person类必须依赖于Apple类，如果Apple类没完成，则编译都不能通过

2.不能再更改，当person想再吃别的水果的时候，无法进行修改

3.很难共享给其他人，只能单独使用

4.person类要对Apple的整个生命周期负责，两个类始终耦合在一起

 

 

 

情况2 通过中介得到

Class person{

   Eat(String name){

  Apple a=(Apple)Fruitfactory.getInstance(“name”);

}}

第二种方式：1.通过使用工程类，间接得到需要的对象

通过使用工程类，程序效果确实得到了改进，但是问题依然存在

缺点：1.每个子类的生成的代码都写死在工厂类里面了，如果要换个子类，则必须更改工厂类中的方法

                2.面向接口编程，一般都会使用工厂类，一般每个接口都会对于一个工程类，当项目非常大的时候，则会有非常多的工厂类

   

情况3.直接被注入
Class person{

   Eat(Fruit fruit){

  //apple为Fruit实现类

}

}

  

第三种方式：只需要在外部传入一个现成的对象给方法调用，不同的实现传入不同的对象即可（感觉这么说就是简单的面向接口的编程的好处，具体优势，请看后面）

 

 

在系统中，我们可以用一个外部的容器Container 来统一调配整个系统的运行，将对象的创建和获取提取到外部容器，由外部容器为每个组件提供需要的组建.

例如：

在容器中创建Fruit类对象apple，

将Person类依赖的Fruit对象传递给Person类

 

将了这么多，那么，到底是控制的什么被反转了呢?

获得依赖对象的方式被反转了.

也就是说

将一个对象如何获取它所依赖的对象这个任务的控制权反转到外部容器中。对象的依赖都是在对象创建时，由负责协调整个系统中各个实体间关系的外部容器提供了。

 

 

了解了IOC的基本理念后

剩下的问题就是：怎么样把类中依赖的对象的引用传递给类？（我们把这种将依赖对象的引用传递给类的方式叫做注入）

接下来，我们需要研究，有几种方法，可以把对象注入到类的内部

注入的三种方式： 

1．  通过接口注入

      这种方式要求我们自己定义的组建类必须实现容器给定的一个接口，然后容器通过这个接口，为我们的组建类注入所依赖的类

      缺点：容器对组建的侵入性会很强，实现的组建只能给此容器用了，移植性不强

 

2．  Setter注入

      在容器中，通过调用对象的setter()方法，将该对象的依赖传递到类当中

 

3．构造器注入

     通过使用构造器，在类初始化的时候，传入对象的依赖

 

 

知道了在容器中可以有三种方式把一个类的对象的依赖传入到这个对象的当中去，但是，这个类的对象我们到底该怎么得到呢？它的依赖又该怎么得到呢？

难道也是在容器中，简单的通过new得到不同的对象，然后进行相互调用吗?

 

如果是这样的话，那么我们仅仅只是完成了一些基于依赖倒转的代码重构工作而已，并没有真正的体现系统的动态性

那么我们该怎么样才能最大程度的体现系统的动态性? 怎么样才能最大程度的将两个类之间的依赖降低，实现解耦合呢？

 

我们可以给系统一个XML的配置文件，

在该XML配置文件中，设置每个对象的相应的属性信息（即该类的具体依赖）

然后在系统中，解析XML文件得到一个实体类obj类，obj类保留没一个对象的配置信息

然后根据反射原理，利用解析得到的obj类中信息，动态的生成配置对应的对象，并且调用对象的setter()方法，完成对该对象的注入，

因为XML只是一个符合一定格式要求的文本文件，

所以我们可以随时更改XML文件，而不修改源代码

来得到我们需要的任何类型的任何一个对象，并完全对该对象的注入

使该对象的依赖得以进行，并能使系统最大程度的动态化，具有可拓展性

 

 

IoC核心理念：

1.在类当中不创建对象，在代码中不直接与对象和服务连接

2.在配置文件中描述创建对象的方式，以及各个组件之间的联系

3.外部容器通过解析配置文件，通过反射来将这些联系在一起

 

The Hollywood principle：Don’t call us,we’ll call you.

即，所有组件都是被动的、不主动联系（调用）外部代码，

要等着外部代码的调用--------所有的组件的初始化和相互调用都由容器负责实现。

简单的说，就是整个程序之间的关系，都由容器来控制:将程序的控制权反转给容器,就是所谓的外转

而在我们传统代码中，由程序代码直接控制

 

 

最后，使用一个比较形象的例子来最后阐述一次IOC的作用：

 

　  所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号………，想办法认识她们，投其所好送其所要，然后嘿嘿……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。

 

那么IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，然后婚介就会按照我们的要求，提供一个mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制。

Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转。

 

IoC的一个重点,是在系统运行中动态的向某个对象提供它所需要的其他对象。这一点是通过DI（Dependency Injection，依赖注入）来实现的。比如对象A需要操作数据库，以前我们总是要在A中自己编写代码来获得一个Connection对象，有了 spring我们就只需要告诉spring，A中需要一个Connection，至于这个Connection怎么构造，何时构造，A不需要知道。在系统运行时，spring会在适当的时候制造一个Connection，然后像打针一样，注射到A当中，这样就完成了对各个对象之间关系的控制。A需要依赖 Connection才能正常运行，而这个Connection是由spring注入到A中的，依赖注入的名字就这么来的。那么DI是如何实现的呢？ Java 1.3之后一个重要特征是反射（reflection），它允许程序在运行的时候动态的生成对象、执行对象的方法、改变对象的属性，spring就是通过反射来实现注入的。

 

 

 

附注：因为参考的文章和Blog太多，无法一一表示感谢.谨在此特别感谢CSDN博客的it_man大神

和http://www.zhuoda.org/xiaoming/66303.html的作者

以及百度百科作者、维基百科作者

以及javaeye上的多为写了ioc的兄弟

 

 

恩，IOC原理折腾了一天总算搞明白了。接下来自己动手写个玩具Spring吧。

 

评论

8 楼 qingtianzhu 2012-06-06  

有点感悟了，前段时间看这个IOC有点迷糊，这次总算有点明白，以后楼主多写点这样的文章，不需要太华丽的语言，只要能看懂就行了，期待你的新文章

7 楼 jiahut 2010-12-02  

      “怎么样才能最大程度的将两个类之间的依赖降低，实现解耦合呢？”
不仅仅是XML，还可以通过注解。我就喜欢注解驱动的编程。
      那我问一个问题：依赖关系什么时候被确定的？

6 楼 java_mzd 2010-12-01  

zdjray 写道

最后一句可不容易啊

呵呵，是不容易啊。
但是终于还是写完了。
http://java-mzd.iteye.com/blog/829890
欢迎拍砖

5 楼 java_mzd 2010-11-30  

kxyk 写道

“IOC(inview of control)控制反转”

第一句就写错了。。。
IoC是Inversion of Control，不是inview

呵呵，好毒的眼神啊，惭愧惭愧。。。

4 楼 kxyk 2010-11-30  

“IOC(inview of control)控制反转”

第一句就写错了。。。
IoC是Inversion of Control，不是inview

3 楼 java378656992 2010-11-29  

    这篇文章让我收获良多！ IOC 设计模式，目前已经运用的非常广泛。一直没有像楼主这样狠心专研技术的毅力。 因此很多技术对我而言，只是刚巧会用，完全是照猫画虎，对其中原理一直不太关注。 作为程序员来说，这的却是非常汗颜的！
     总得来说，要多像楼主学习了！  希望楼主有什么好的设计模式思想或者经验，多多在博客上分享！
 

2 楼 zdjray 2010-11-25  

最后一句可不容易啊

1 楼 cnsuifeng 2010-11-21  

谢谢 以前理解的只是皮毛 现在有点收获了