架构师之路(5)---IoC框架

1 IoC理论的背景
    我们都知道在面向对象的应用中，软件系统都是由N个对象组成的，它们通过彼此的合作，最终实现业务逻辑。

 
图1：耦合在一起的对象

    如果我们打开机械式手表的后盖，就会看到与上面类似的情形，各个齿轮分别带动时针、分针和秒针顺时针旋转，从而在表盘上产生正确的时间。上图画的就是这样的一个齿轮组，它拥有多个独立的齿轮，这些齿轮相互啮合在一起，协同工作，来共同完成某项任务。我们可以看到，在齿轮组中，如果有一个齿轮出了问题，就可能会影响到整个齿轮组的运转。

    齿轮组中各个齿轮之间的啮合关系,与软件系统中对象与对象之间的耦合关系，非常类似。对象之间的耦合关系是必要的，是协同工作的基础，当然也是无法避免的，否则无法保证系统整体的正常运转。目前，很多工业级的应用越来越庞大，对象之间的依赖关系也越来越复杂，就会出现对象之间的多重依赖性关系，因此，架构师和设计师对系统进行分析和设计将面临很大的挑战。对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形。

 

 
图2：对象之间复杂的依赖关系

    耦合关系不仅会出现在对象与对象之间，也会出现在软件系统的各模块之间，以及软件系统和硬件系统之间。如何降低系统之间、模块之间和对象之间的耦合度，是软件工程永远追求的目标之一。
    所以有人就提出来IOC理论，用来实现对象之间的“解耦”，目前已被广泛应用于很多项目中。

2 什么是控制反转(IoC)
    IoC是Inversion of Control的缩写，多数书籍翻译成“控制反转”，还有些书籍翻译成为“控制反向”或者“控制倒置”，这些都大同小异，我个人觉得这个翻译有待商榷，容易引起歧义，是不是翻译为 “控制转移”会更好一些。
    1996年，Michael Mattson在一篇有关探讨面向对象框架的文章中，首先提出了IoC 这个概念。对于面向对象设计及编程的基本思想，前面我们已经讲了很多了，不再赘述，读者可以参考我前面的文章，简单来说就是把复杂系统分解成相互合作的对象，这些对象类的内部实现是透明的，从而降低了解决问题的复杂度，而且可以灵活地被重用和扩展。IoC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦，如下图：

 

 图3：IoC解耦示意图

    大家看到了吧，由于引进了中间的“第三方”，也就是IoC容器，使得A、B、C、D这4个对象没有了耦合关系，齿轮之间的传动全部依靠“第三方”了，所有对象的控制权全部上缴给“第三方”，这就是“控制反转”说法的由来，意思就是各个对象的控制权都被转移给“第三方”了。
    从另一个角度来看，作为“第三方”的IoC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“粘合剂”，对象与对象之间会彼此失去联系，这就是所谓的Ioc容器被称为“粘合剂”的原因。
    我们再把上图中间的Ioc容器拿掉后，整个系统变为这样的情形：
 

图4：拿掉IoC容器后的系统

    拿掉IoC容器后，我们看到的就是系统开发所需要完成的全部内容，这时候，A、B、C、D这4个对象之间已经没有了耦合关系，彼此毫不影响，所以当你在实现Class A的时候，根本不用再考虑B、C和D了，系统对象之间的依赖已经降低到了最低程度。至于IoC容器，你可以到开源组织的网站上找一找，里面有很多比较成熟而且Free的，使用起来非常简便。
如果真能实现控制反转，对于系统开发而言，这将是一件多么美好的事情！

 

3 什么是依赖注入(DI)
    我们先看一些生活中的例子，帮助你理解依赖注入(DI)：

3.1 主机和内置硬盘
    我们平时所用的电脑，它的硬盘安装在主机里面，从电脑的外部，我们是看不见硬盘的。所以，我们通常认为，电脑的所有部件是融为一体的。
 

图5：主机和内置硬盘

    对于一体机而言，一旦出现了问题，我们可能无法准确地判断到底是什么零部件出现了问题，有可能是CPU坏了，也有可能是主板烧了，还有可能是内存松动了。还有的时候，比如，电脑硬盘出现了问题，可能导致整台电脑都无法使用。从这个例子，我们可以看到部件之间“紧密耦合”的产生的问题：无法准确的定位和诊断故障所在。这种情形，在软件工程的理论中，称之为可理解性和可测试性差。

    如果你想修理电脑的硬盘，那么在修理过程中就必须小心翼翼，不要把其它的部件再搞坏了，比如不慎把内存给碰松动了，硬盘固然是修好了，但整台电脑仍然无法使用。这种情形，在软件工程的理论中，称之为可修改性差。
可理解性、可测试性、可修改性组成了系统的可维护性，一体机的可维护性就表现得比较差。

 

3.2 主机和USB设备
    大家对USB接口和设备应该都很熟悉。自从有了USB接口，给我们使用电脑带来了很大的方便，现在有很多的外部设备都支持USB接口。
 

图6：主机和USB设备

 

    从软件工程角度，我们分析一下USB带来的好处：
1、USB设备作为主机的外部设备，在插入主机之前，与主机没有任何的关系，两者都可独立进行测试，无论两者中的任何一方出现什么的问题，都不会影响另一方的运行，所以可维护性比较好。
2、同一个USB设备可以插接到不同的支持USB的任何主机，也就是USB设备可以被重复利用，所以可复用性比较好。
3、支持热插拔，只要是支持USB接口的设备都可以接入，所以可扩展性比较好，非常灵活。

3.3 依赖注入
    2004年，Martin Fowler从另一个角度来思考这个问题，提出了“哪些方面的控制被反转了？”这样一个问题，并给出了答案：“依赖对象的获得被反转”。于是，他给“控制反转”取了一个他认为更合适的名字叫做“依赖注入（Dependency Injection）”。他的这个答案，实际上点明了实现IoC理论的解决方法。所谓依赖注入，就是由IoC容器在运行期间，动态地将某种依赖关系注入到对象之中。

    依赖注入(DI)和控制反转(IoC)是从不同的角度的描述的同一件事情，都是指通过引入第三方，即IoC容器，实现软件系统中对象之间的解耦。

    控制反转能够带给系统开发的好处，与USB机制带来的好处基本类似，而且依赖注入的实现跟USB机制也完全一样。USB机制是现实中依赖注入的很好的案例。我们用一个实际的例子，分析一下USB机制：

任务：主机通过USB接口读取一个文件。
思路：首先，必须制定一个USB接口标准，主机对USB设备的访问严格按照USB接口标准，USB设备提供的功能也必须符合USB接口标准。
    当主机需要获取一个文件的时候，它直接去读取USB接口，根本不会关心USB接口上连接的是什么设备。
如果我给主机连接上一个U盘，那么主机就从U盘上读取文件；如果我给主机连接上一个外接硬盘，那么主机就从外接硬盘上读取文件。选取何种外部设备的权力由我说了算，也就是控制权归我。
至此,依赖注入的思路已经非常清楚：当主机需要读取文件的时候，我就把它所要依赖的外部设备，挑出来一个，帮他挂接上。这个过程就是一个被依赖的对象在系统运行时被注入另外一个对象内部的过程。在这个过程中，我就起到了IoC容器的作用。

    我们再把依赖注入应用到软件工程中：
    Class A依赖于Class B,当Class A需要用到Class B的时候，IoC容器就会立刻创建一个Class B送给Class A使用。IoC容器就是一个类制造工厂，你需要什么，直接来拿，直接用就可以了，而不需要去关心你所用的东西是如何制成的，也不用关心最后是怎么被销毁的，这一切全由IoC容器包办。

 

  4 实现IoC容器

 ----------------------------------------------------

后记：之所以突然跳跃到39，是因为有的同学基础比较好，已经没有必要阅读有关面向对象、设计模式以及软件工程的基本理论，那么可以从这里开始阅读。基础需要继续补全的同学，可以从4继续看，我会定期在两个方向进行更新。框架理论，是架构师知识体系中非常重要的部分，我会逐步结合实例，把常见的一些框架方面的知识与大家共享。