控制反转为程序开发带来的好处是什么？

 IOC全称是Inversion of Control，即反转控制,或者说是依赖注入更为合适。选择别纠结这些全称的专业词。我们可以用别外一些方式去理解它，IOC，是一种设计模式。它的延生所要实现的是把藕合从代码中移出去，统一放到XML文件中，通过一个容器在需要的时候把这个依赖关系形成，即把需要的接口实现注入到需要它的类中，这可能就是“依赖注入”说法的来源了。

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

看了这些，头晕没？ 没关系，继续。IOC中最基本的Java技术就是“反射”编程，至天反射机制，可以查看我的另一篇《java中的反射机制》.如果你理解了反射，你就知道，IOC，就是为了动态的创建对象，而不是在代码中写死去生成某一种特定的对象。通过IOC模式，我们可以通过改变XML上的配置文件，去改变各种的依赖关系。每当IOC容器去读取XML文件后，就会根据给出了的类名来生成对象。所以当我们需要换一个实现子类将会变成很简单（一般这样的对象都是现实于某种接口的），只要修改XML就可以了，这样我们甚至可以实现对象的热插拨（有点象USB接口和SCIS硬盘了）。

下面来说说IOC的缺点吧，了解其缺点可以更进一步的了解其用法。

（1）生成一个对象的步骤变复杂了（其实上操作上还是挺简单的），对于不习惯这种方式的人，会觉得有些别扭和不直观。

（2）对象 生成因为是使用反射编程，在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说，这点损耗是微不足道的，除非某对象的生成对效率要求特别高。

（3） 缺少IDE重构操作的支持，如果在Eclipse要对类改名，那么你还需要去XML文件里手工去改了，这似乎是所有XML方式的缺憾所在。