IoC,全称是Inversion of Control,即控制反转.IoC模式,又称为DI,即Dependency Injection,叫做依赖注入或依赖注射.IoC容器,即实现了IOC模式的容器,如Spring IoC(IoC容器只是Spring的一部分),Pico,Jdon等等.以上三个概念是完全不同的,不能混淆!
"IoC设计模式,重点关注组件的依赖性,配置以及生命周期."它主要是为了解决程序设计中松散耦合的问题,依赖关系不出现在任何代码中,而只出现在XML配置文件里.如Spring当中的:
<bean id="b" class="test.B">
<property name="a"><ref bean="a"/></property><!-- 必须指定调用关系 -->
....
</bean>
<bean id="a" class="test.A">
<bean id="c" class="test.C">
又如Jdon中的:
<app>
<services>
<pojoService name="b" class="test.B"/>
<pojoService name="a" class="test.A"/>
<pojoService name="c" class="test.C"/>
</services>
</app>
但Spring IoC并没有完全的实现脱离依赖关系,它还是出现在了配置文件中,而Jdon做到了(并不是说Spring不如Jdon,只是在这一点上,Jdon作的更好).
"我们知道,在Java基本教程中有一个定律告诉我们:所有的对象都必须创建;或者说:使用对象之前必须创建,但是现在我们可以不必一定遵循这个定律了,我们可以从IoC容器中直接获得一个对象然后直接使用,无需事先创建它们。"初期的OO编程都用new,实例化一个对象来使用.后来为了方便控制,开始使用接口模式,通过实现接口来操作.但随着技术的发展,这种紧耦合的方式已经不能适应,于是出现了工厂模式.但工厂模式也没能完全实现松散耦合(有人说IoC也不能,不可能实现完全的松散耦合),于是就出现了IoC模式&IoC容器.
--------- IoC 简介 --------------
IOC是一种新的设计模式,即IOC模式,系统中通过引入实现了IOC模式的IOC容器,即可由IOC容器来管理对象的生命周期、依赖关系等,从而使得应用程序的配置和依赖性规范与实际的应用程序代码分开。其中一个特点就是通过文本的配件文件进行应用程序组件间相互关系的配置,而不用重新修改并编译具体的 Java代码。
当前比较知名的IOC容器有:Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。
在上面的几个IOC容器中,轻量级的有Pico Container、Avalon、Spring、HiveMind等,超重量级的有EJB,而半轻半重的有容器有JBoss,Jdon等。
可以把IoC模式看做是工厂模式的升华,可以把IoC看作是一个大工厂,只不过这个大工厂里要生成的对象都是在XML文件中给出定义的,然后利用Java 的“反射”编程,根据XML中给出的类名生成相应的对象。从实现来看,IoC是把以前在工厂方法里写死的对象生成代码,改变为由XML文件来定义,也就是把工厂和对象生成这两者独立分隔开来,目的就是提高灵活性和可维护性。
IoC中最基本的Java技术就是“反射”编程。反射又是一个生涩的名词,通俗的说反射就是根据给出的类名(字符串)来生成对象。这种编程方式可以让对象在生成时才决定要生成哪一种对象。反射的应用是很广泛的,象Hibernate、String中都是用“反射”做为最基本的技术手段。
在过去,反射编程方式相对于正常的对象生成方式要慢10几倍,这也许也是当时为什么反射技术没有普通应用开来的原因。但经SUN改良优化后,反射方式生成对象和通常对象生成方式,速度已经相差不大了(但依然有一倍以上的差距)。
IoC最大的好处是什么?因为把对象生成放在了XML里定义,所以当我们需要换一个实现子类将会变成很简单(一般这样的对象都是现实于某种接口的),只要修改XML就可以了,这样我们甚至可以实现对象的热插拨(有点象USB接口和SCIS硬盘了)。
IoC最大的缺点是什么?(1)生成一个对象的步骤变复杂了(其实上操作上还是挺简单的),对于不习惯这种方式的人,会觉得有些别扭和不直观。(2)对象生成因为是使用反射编程,在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说,这点损耗是微不足道的,除非某对象的生成对效率要求特别高。(3)缺少IDE重构操作的支持,如果在Eclipse要对类改名,那么你还需要去XML文件里手工去改了,这似乎是所有XML方式的缺憾所在。