IoC--Inversion of Control 控制反转

DI--Dependency Injection 依赖注入

控制反转和依赖注入是对同一事情的不同角度描述。依赖注入是从应用程序的角度描述--应用程序依赖容器创建并注入它所需要的外部资源；控制反转是从容器的角度在描述--容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。   

案例分析：许多大型应用都需要2个甚至多个类彼此的合作来实现业务逻辑，这需要每个对象都需要与其合作的对象（也就是它所依赖的对象） 的引用。如果这个获取过程需要自己实现，那将导致代码高度耦合并难以测试。IOC亦称“依赖倒置原理”（Dependency Inversion Principle）。控制反转是Spring框架的核心。

应用控制反转，对象在被创建的时候，有一个调控系统内所有的对象的外界实体，将其所依赖的对象的引用，传递给它。也就是说，依赖被注入到对象中。所以，控制反转是一个关于对象如何获取他所依赖对象的引用，这个过程的反转。  

 工厂方式的本质是选择实现，并没有改变原来的耦合状态。但IOC却可以彻底解决这种耦合，它把耦合从代码中移出去，放到统一的XML文件中，通过一个容器在需要的时候把这个依赖关系形成，即把需要的接口实现注入到需要它的类中，这可能是“依赖注入”说法的来源了。

IOC模式，系统中通过引入实现了IOC模式的容器，即可由IOC容器来管理对象的生命周期、依赖关系等，从而使得应用程序的配置和依赖性规范与实际的应用程序代码分开。其中一个特点就是通过文本的配置文件进行应用程序组件间相互关系的配置，而不需要重新修改并编译具体的代码。  

  当前比较知名的IOC容器有： Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。

可以把IOC模式看做是工厂模式的升华，可以把IOC看做是一个大工厂，只不过这个大工厂里要生产的对象都是在xml文件中给定义的，然后利用Java的反射编程，根据xml中给出的类名生成相应的数据。从实现看，IOC是把以前写死在工厂方法里的对象改由在xml文件中定义，这样的目的是提高灵活性和可维护性。   

IOC的优点和缺点：

IOC把对象生成放在了xml里定义，可以实现对象的热插拔；缺点是（1）生成一个对象的步骤变复杂了， 对于不习惯这种方式的人，会觉得别扭和不直观。 （2）生成的对象使用反射编程，效率上会有损耗，但相对应IOC提高的维护性和灵活性来说，这点损耗是微不足道的，除非某对象的生成效率要求特别高。（3）缺少IDE重构操作的支持，如果在Eclipse要对类改名，那么还需要在配置xml文件中做相应修改。