白话IoC

Java Spring Framework是JAVAEE开发过程中经常使用到的框架，这个框架最大的特色就是IoC和AOP。那么什么是IoC和AOP呢。

IoC，Inversion of Control的缩写，翻译过来就是控制反转。AOP，Aspect Oriented Programming的缩写，翻译过来就是面向切面编程。

由此可见，发明一种概念，抽象成几个单词，然后取首字母大写，再写个几千页的文档，看来这是成为架构设计师的必经之路了。框架的创作过程总是在把具体的事务进行高度抽象，而学习和应用框架的过程就得把这个过程逆转过来。

看到很多的解释都有点附庸风雅，就像说话时不时的蹦点英文就让自己显得洋气一点。我还是来点土的吧，今天先说说IoC。

比如，上个世纪的时候想租房，我会把自己的租房信息通过写传单和小广告的方式发布出来，还会通过朋友四处打听房源，经过大量的实地考察，终于锁定一个目标，然后和房东讨价还价。有必要的话，还要自己写个协议，列个清单等等，防止以后扯皮。一圈下来，折腾个半死。中途要是房东反悔，整个过程再来一遍。前边的工作基本白做。

这个过程对应到Java编程，当我的程序中需要用到一个任务实现的时候，作为一个懒人，第一反应就会四处查找对应的类库（自己不发明轮子，自己也不比别人聪明，拿来主义。整个过程就有点像找房源），下载下来，通读api，写好调用。好了，随着程序不断增长，莫名的出现了bug，原来是手欠把以前某个稳定版本的库替换成了升级版，但是又舍不得回到以前的版本，现有的库确实优点多多，怎么办？再找，再排查，再下载，再看源码，替换，重编译，重部署。好了，一圈下来，折腾半死。当程序规模扩大的一定程度的时候，各个外部类库的依赖度逐步增加，还时不时的更新，再放出点bug，如果继续采用这种方式，结果可想而知，坑爹了。

传统代码组织方式的特点：类库之间依赖耦合度过高，程序实现过程的控制半径过大。

回到今天，同样是租房，整个过程就轻松简单多了。我只需要登录某个租房网站，或者到某个房屋中介把需求发布出来，至于后边的过程，全部由中介完成。如果我想出租房屋，同样也只需要把我的要求发布给中介，让中介来配对，管理，提供服务。由于出现了中间层，我的需求与房源供应之间产生了隔离。中间层负责协调安排、并处理变动。

控制反转，还有一个名词叫依赖注入，我个人觉得还不如叫控制中介来的实在。

对应Spring，这个中间层就是IoC container，这是个抽象概念。具体实现起来，对应的就是xml（现有版本已经进化到不仅仅依赖于xml定义类关系了）。通过xml的定义，把需要用到的类定义在xml 的bean里（类似于在中介发布需求，进行登记）。然后按照Spring的语法规则，调用对象实例的生成方法，把生成的对象注入到要使用该对象的主体类中。这就建立起了调用者和被调用者之间的映射关系（说白了，是在进行映射匹配）。一旦这种关系确立起来，两者之间就产生了隔离。被调用者一旦发生变化，只需要在登记的地方进行变更，而不必侵入到调用者的代码空间中进行修改。当然，中间层不是乱登记匹配的，两者之间要有接口规范进行约束。我想租两居室，中介就要按这个规范进行登记匹配，给我几个两居室的房源进行选择，随时可以替换。

这有点像u盘，只要有usb接口，随时热插拔，即插即用。