大牛吹了那么久的ioc，今天才了解那么点点。

实际上IOC就是工厂模式的进化，
即将创建对象跟使用对象分割。

如果说工厂模式还不能彻底解决耦合，因为客户端会和工厂类耦合，那 IOC 则进一步了，如果客户端和

被调用者都 IOC 容器内，则客户端就只和具体被调用者得接口耦合，OO中同步系统目前做到和接口耦合

就算是松耦合了（JMS等异步则完全解耦）。

比如我下一次要用到这次系统的几个类，如果在工厂模式下
则
object object=Factory.getObject("beanname");
而IOC下，
只需在配置文件中指定
<bean class="*.*.*.object"><property name="object">重用类</property></bean>
即可，
而object更可为一个接口，那么在不同的系统中，需要重用的类只需实现此接口就可以了。
从而实现dependency injection中所描述的，插件构造系统。
此谓之插件组合系统，是因为集成了很多个可以重用的类，从而使得这些重用的类成为“插件”，而当

前系统只需实现这些类的接口即可拔插组件。

依赖注射 ：垃圾回收机制的镜像
Dependency Injection -- the mirror of Garbage Collection

作者使用垃圾回收机制做比喻，通过引入这个机制，解放了开发者，开发者不用再照顾垃圾回收这个问

题； IOC 则起到同样效果，开发者不用再关系对象之间依赖了，只管使用就可以了。

IOC容器就是预先将需要调用的类装入其中，就像个蒸笼，要拿包子的时候从里面拿就是了，不对，应该

是个自动送包子的蒸笼，我只要在我座位上标志我像吃包子了，这个蒸笼就自己把包子给我端上来了。

一个是抽象一个是实体，这么让抽象关联上实体？new。但是这样维护性降低了很多，所以将这个关系拿

到IOC容器中去，好办多了。

我的总结：

ioc的美德就是一个字：懒。

每个模块只关心自己那一点点功能。遇到须要别的功能的，什么是最简单的办法？
狮子大开口，定义一个接口，说：我要这个功能。
然后要求构造函数传递进来就行了。

有比这更省事的吗？为什么我们的程序员总是学不会懒惰呢？

多年的面向过程，面向实现的训练让他们遇事都是老老实实地想着直接去解决。从来没有想过有时候做

一件事情比不做一件事情糟糕得多！

ps:哈哈，ajoo说出了我很想说的一气话！！再翻翻martin的例子，插件？对了啊！就是少写点代码要更

多功能就张开嘴巴挂个牌子吧，我还要这个功能，给我吧。在深入下去，martin大师说的例子，本系统

实现一个接口，然后很多实现类，就像我挂牌子说我要吃包子，不管什么包子都可以，今天想吃韭菜的

，每天想吃肉的，反正只要实现包子接口的我都吃,只是偶尔跟心情有关系罢了。拿我朋友也想吃包子怎

么办？他也张开嘴巴挂个牌子说“我要吃包子。”嘛，朋友不喜欢吃韭菜跟肉的，而喜欢吃豆沙的怎么

办？那他自己叫人做些吧，反正只要学我的张开嘴巴挂个牌子就能吃了（只是苦了那个做包子的），只

要做好包子就够啦，想想也是，如果一方面要考虑包子怎么做，又要考虑是拿手掰开吃还是拿筷子夹着

吃，那可真累人，现在好啦，他只要重复我的绝大多数动作就够啦。

废话了一大堆，原来martin考虑得那么深啊，不仅把ajoo说的“懒”字当头说通了，而且还说了同一种

功能有X种实现的时候，我们应该做个统一接口以方便以后使用不同功能。

总之，对象在编码实现的时候，对象创建根本不需要我操作，直接拿来用就是了，就像小吃店蒸笼里的

包子，拿来就可以吃了，而不要重新做包子。使得一个个包子都成为插件。有了IOC，你难道不想多用几

次以前写过的代码吗？

总结那么久，IOC原理有2大好处。
1、功能更内聚(几乎都一块一块的了)，使得重用性更高。
2、功能更具有多态性，比如只要实现一个接口只需injection进去就可以实现同样方法却调用不同资源

。