IOC的深刻理解 和《两个个很形象的依赖注入的比喻》

相关网址
http://martinfowler.com/articles/injection.html http://www.contextfree.net/wangyw/source/dip_ioc.html

IoC是什么？Inversion of Control，即反转控制，或许说为依赖注入更为合适。IoC就是IoC，不是什么技术，与GoF一样，是一种设计模式。

Interface Driven Design接口驱动，接口驱动有很多好处，可以提供不同灵活的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执行：AInterface a = new AInterfaceImp(); 这样一来，耦合关系就产生了，如：
Class A{
AInterface a;
A(){}
aMethod(){
a = new AInterfaceImp();
}
}
ClassA与AInterfaceImp就是依赖关系，如果想使用AInterface的另外一个实现就需要更改代码了。当然我们可以建立一个Factory来根据条件生成想要的AInterface的具体实现，即：
InterfaceImplFactory{
AInterface create(Object condition){
if(condition = condA){
return new AInterfaceImpA();
}elseif(condition = condB){
return new AInterfaceImpB();
}else{
return new AInterfaceImp();
}
}
}
表面上是在一定程度上缓解了以上问题，但实质上这种代码耦合并没有改变。通过IoC模式可以彻底解决这种耦合，它把耦合从代码中移出去，放到统一的XML文件中，通过一个容器在需要的时候把这个依赖关系形成，即把需要的接口实现注入到需要它的类中，这可能就是“依赖注入”说法的来源了。
IOC模式，系统中通过引入实现了IOC模式的IOC容器，即可由IOC容器来管理对象的生命周期、依赖关系等，从而使得应用程序的配置和依赖性规范与实际的应用程序代码分开。其中一个特点就是通过文本的配件文件进行应用程序组件间相互关系的配置，而不用重新修改并编译具体的代码。
当前比较知名的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方式的缺憾所在。
IOC实现初探
IOC关注服务(或应用程序部件)是如何定义的以及他们应该如何定位他们依赖的其它服务。通常，通过一个容器或定位框架来获得定义和定位的分离，容器或定位框架负责：

保存可用服务的集合

提供一种方式将各种部件与它们依赖的服务绑定在一起

为应用程序代码提供一种方式来请求已配置的对象(例如，一个所有依赖都满足的对象)， 这种方式可以确保该对象需要的所有相关的服务都可用。

现有的框架实际上使用以下三种基本技术的框架执行服务和部件间的绑定:

类型1 (基于接口): 可服务的对象需要实现一个专门的接口，该接口提供了一个对象，可以从用这个对象查找依赖(其它服务)。早期的容器Excalibur使用这种模式。

类型2 (基于setter): 通过JavaBean的属性(setter方法)为可服务对象指定服务。HiveMind和Spring采用这种方式。

类型3 (基于构造函数): 通过构造函数的参数为可服务对象指定服务。PicoContainer只使用这种方式。HiveMind和Spring也使用这种方式。

//*************************************************************************

//*************************************************************************

//*************************************************************************

//*************************************************************************

//*************************************************************************

//*************************************************************************

//*************************************************************************

何谓控制反转（IoC = Inversion of Control），何谓依赖注入（DI = Dependency Injection）？一直都半懂不懂，今天看到两个比喻，觉得比较形象。
IoC，用白话来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓"控制反转"的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。
正在业界为IoC争吵不休时，大师级人物Martin Fowler也站出来发话，以一篇经典文章《Inversion of Control Containers and the Dependency Injection pattern》为IoC正名，至此，IoC又获得了一个新的名字："依赖注入 （Dependency Injection）"。相对IoC 而言，"依赖注入"的确更加准确的描述了这种古老而又时兴的设计理念。从名字上理解，所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。
一：
再看上例中，笔记本电脑与外围存储设备通过预先指定的一个接口（USB）相连，对于笔记本而言，只是将用户指定的数据发送到USB接口，而这些数据何去何从，则由当前接入的USB设备决定。在USB设备加载之前，笔记本不可能预料用户将在USB接口上接入何种设备，只有USB设备接入之后，这种设备之间的依赖关系才开始形成。
对应上面关于依赖注入机制的描述，在运行时（系统开机，USB 设备加载）由容器（运行在笔记本中的Windows操作系统）将依赖关系（笔记本依赖USB设备进行数据存取）注入到组件中（Windows文件访问组件）。这就是依赖注入模式在现实世界中的一个版本。
很多初学者常常陷入"依赖注入，何用之有？"的疑惑。想来这个例子可以帮助大家简单的理解其中的含义。依赖注入的目标并非为软件系统带来更多的功能，而是为了提升组件重用的概率，并为系统搭建一个灵活、可扩展的平台。将USB接口和之前的串/并、PS2接口对比，想必大家就能明白其中的意味。
二：
首先想说说IoC（Inversion of Control，控制倒转）。这是spring的核心，贯穿始终。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号………，想办法认识她们，投其所好送其所要，然后嘿嘿……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。
　　那么IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，然后婚介就会按照我们的要求，提供一个mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转。