所谓IoC, 就是一个用XML来定义生成对象的模式。
1、现有三个类，Human是接口，Chinese是一个实现类，American是另一个实现类。
2、获取以上对象采用工厂模式的用法如下:
创建一个工厂类Factory，如下:
3. 下面是一个测试的程序，使用工厂方法来得到了不同人种的“对象”，并执行相应的方法。
4、采用Spring的IoC的用法如下:
在项目根目录下创建一个bean.xml文件:
总结
(1) 也许有人说，IoC和工厂模式不是一样的作用吗，用IoC好象还麻烦一点?
举个例子，如果用户需求发生变化，要把Chinese类修改一下。那么前一种工厂模式，就要更改Factory类的方法，并且重新编译布署。而IoC只需要将class属性改变一下，并且由于IoC利用了Java反射机制，这些对象是动态生成的，这时我们就可以热插拨Chinese对象(不必把原程序停止下来重新编译布署).
(2) 也许有人说，即然IoC这么好，那么我把系统所有对象都用IoC方式来生成?
注意，IoC的灵活性是有代价的：设置步骤麻烦、生成对象的方式不直观、反射比正常生成对象在效率上慢一点。因此使用IoC要看有没有必要，我认为比较通用的判断方式是：用到工厂模式的地方都可以考虑用IoC模式。
(3) 关于IoC的低侵入性。
什么是低侵入性？如果你用过Struts或EJB就会发现，要继承一些接口或类，才能利用它们的框架开发。这样，系统就被绑定在Struts、EJB上了，对系统的可移植性产生不利的影响。如果代码中很少涉及某一个框架的代码，那么这个框架就可以称做是一个低侵入性的框架。
Spring的侵入性很低，Humen.java、Chinese.java等几个类都不必继承什么接口或类。但在ClientTest里还是有一些Spring的影子：FileSystemXmlApplicationContext类和ctx.getBean方式等。
现在，低侵入性似乎也成了判定一个框架的实现技术好坏的标准之一。
可以把IoC模式看做是工厂模式的升华，可以把IoC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，然后利用Java 的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。