关于spring的IoC本质

关于spring的IoC本质

我最早接触IoC（Inversion of Control）是在Android刚出来的时候，那个时候的Android版本是1.5，大概是09年，市面上有基本关于Android的书讲到了这个概念。碰巧，当时正好做和操作系统相关的事情，对这个概念深有体会。感觉“控制反转”这个概念很有意思，有意思的地方在于，既然是“反”，那么它的“正”是什么呢？

控制(Control)

程序里面，两个模块A、B之间的关系，有两中：

• 上下级：A调B（B调A是一个意思）
• 平级：A和B互相调用

同时，对于A调B又有两种理解：A调用B，B被A调用；区别在于主角是谁。

Created with Raphaël 2.1.0 A B

通常，A调B的合作模式是B模块先有，B称之为底层模块，因为它是被调用方（通常的架构图里面，被动方都位于图片的下方）。常见的使用场景是操作系统提供了一套API，在操作系统之上写程序，直接使用操作系统的API，我称之为控制。

控制反转(IoC)

但是，如果A模块先有会怎么样呢？先有A，但是A又是调用者。如果要使假想中的B将来能一起工作，那么之后一定要预先定义协议。比如：spring里的IoC容器就规定，bean里面定义什么名称的函数，则会在初始化的时候被调用。如果，你回过头来再看spring的bean教程，实际上就是在告诉你，作为一个bean，要怎么样才能和容器一起工作。

到这里，也很好理解，毕竟不是谁谁便便的一个B模块就能放进来一起工作的。就好比开车，人使用车，可是人已经有了，所以不管你怎么设计汽车，总要人能够用才行。怎么使用汽车，其实是存在一个潜规则或者协议一样的东西。

其实，IoC随处可见。比如：给浏览器写插件；Linux系统里面写驱动；等等。

平级

若AB的关系是平级，怎么办呢？这个似乎没有定数。这个概念就有点类似于人与人之间的关系，既然是平级，那就有点类似于对象之间的关系。面向对象的那套东西就可以派上用场了。

由来

还有一个问题是：控制反转的概念是怎么产生的？换言之，什么样的场景下面才需要去考虑使用控制反转。

要解决这个问题，首先让我看看spring框架是怎么产生的。

我们假设spring的使用场景是web网站。网站可以看作是一个业务需求，用户给URL，后台生成网页给浏览器。在固定的业务场景下面，如果只是编写一个网站，没问题，怎么写都可以。但是，如果写多了，必然在多个网站间，有些代码是一样的。此时，我们有2种选择：要么写一个公共类库，要么写一个类似于spring那样的框架，也就是写A还是写B的问题。这里有个迷惑性在于如果把spring放在B的位置（虽然是框架，却当作类库来看待）。那么，控制反转的概念就显的很深奥。

本质

写到这里，我想大家应该看出来了，其实IoC的本质还是解决代码冗余的问题。你可能会说，看起来不像。回想一下，我们写代码的首要任务是正确性（不正确的代码是没有意义的），然后是解决代码冗余（所谓冗余，就是重复的代码）。其实，代码的可扩展性、解耦等本质上，也是用来解决代码冗余的问题。

这里的本质，后面的文章我还会多次提到，因为它是写代码的根。