浅谈控制反转（IoC）

Inversion of Control

什么是控制反转？

程序的流程控制权相对于传统的面向过程编程而言发生了反转。下面是维基百科的描述

In software engineering, inversion of control (IoC) is a programming principle. IoC inverts the flow of control as compared to traditional control flow.

看到这里大家可能会觉得云里雾里的…控制反转（Inversion of Control）实际是控制（Control）和反转（Inversion）两个词的组合，所以拨开云雾的关键在于理解控制和反转。

怎么理解“控制”？

程序的流程控制权，决定程序的运行方式和流程。

举个例子，想必大家都知道，要把大象放进冰箱需要三步：1）打开冰箱门；2）把大象放进冰箱；3）关上冰箱门。用一段代码用表示的话，代码可能长这样

void putElephantToRefrigerator() {
    打开冰箱门;
    放进大象;
    关闭冰箱门;
}

int main() {
    putElephantToRefrigerator();
    return 0;
}

不过，冰箱可能已经被塞满放不下大象了，我们需要把冰箱里没用的东西清理掉，再把大象团成团放进去，代码会变成这样

void putElephantToRefrigerator() {
    打开冰箱门;
    清理冰箱；
    把大象团成团；
    放进大象;
    关闭冰箱门;
}
...

当然，我们完全可以先把大象团成团，像这样

void putElephantToRefrigerator() {
    把大象团成团；
    打开冰箱门;
    清理冰箱；
    放进大象;
    关闭冰箱门;
}
...

所以，我们要把大象放进冰箱里都会经过一个流程，目前这个流程是由我们自己控制的。

怎么理解“反转”？

相对于传统的面向过程编程实践而言

• 程序的流程控制权发生了转变
• 应用程序与第三方代码之间的调用关系发生了转变

继续看上面的例子，假如我们有一款极其智能的冰箱，不需要手动开门、关门，只要关心放什么东西进去、怎么放进去（nice，事情变得更简单了），代码会变成这样（考虑设计模式-模板方法）

typedef struct AutoRefrigerator;

struct MyRefrigerator : AutoRefrigerator {
    private void putSomething() {
        ...
    }
}

int main() {
    MyRefrigerator refrigerator;
    refrigerator.put(elephant);
    return 0;
}

代码中“refrigerator.put(elephant);”由框架提供，包含多条子语句（open、close、putSomething…），但putSomething没具体实现，需要我们自己定制。

此时，控制程序流程的不是我们的代码而是框架提供的AutoRefrigerator，程序流程控制权发生了反转，控制权由我们自己的代码转移到了框架中。

控制反转前后有哪些变化呢？

• 反转前：我们自己的代码决定程序的工作流程，并调用第三方代码（我们自己的代码是甲方，第三方代码是乙方）
• 反转后：第三方代码（框架）决定程序的工作流程，并调用我们写的代码（我们自己的代码是乙方，第三方代码是甲方）

可见，在控制反转前我们写的代码会调用第三方代码，而控制反转后则是由第三方代码（框架）调用我们的代码，这种代码调用关系的反转也是控制反转的意义。

有什么好处？

好处？怎么可以这么物质？这个问题超纲了，暂且不谈…笔者是个物质的人，所以只谈谈有什么好处。

好处用两个字概括：复用（用Paul Graham的话来说，复用就是软件圣杯）。

复用代码有三种方式：类库、框架、设计模式。

• 类库：强调代码复用；
  定义一组可复用的代码，供其他程序调用——拿来主义，别人的东西拿来用，用别人的锤子砸核桃。
• 框架：强调设计复用；
  定义程序的体系结构，开发人员通过预留的接口插入代码（做填空题）——把自己的锤子装在流水线上，让它砸核桃。
• 设计模式：复用解决方案；
  设计模式提供了解决一类问题的有效经验，复用这些经验往往可以很好地解决问题——看别人是怎么砸核桃的，依葫芦画瓢模仿一遍。

控制反转为复用框架提供了可能性。框架定义了解决一类问题的流程、体系结构，但程序的特定细节需要定制，因此框架需要调用我们写的代码，控制反转提供了这种可能性。控制反转和编码原则之一的好莱坞原则（It calls me rather me calling the framework） 也存在着紧密的联系。

另外，按照Martin Fowler的描述，控制反转还有Seperating Configuration from Use的作用。实际上这是一些容器的主要作用（如Spring），而这些容器又不可避免地使用了控制反转。

怎么实践？

说了这么多，又有这么诱人的好处，怎么才能得到它呢？

最简单的实践就是设计模式-模板方法，不过最常见的实践方法还是依赖注入和依赖查询。
依赖注入（DI：Dependency Inject）：被动接收依赖对象，由容器将被依赖对象注入到对象内部；
依赖查询（DL：Dependency Lookup）：主动查询依赖对象，由对象自身通过 服务定位器 查询被依赖对象；依赖查询也经常以服务定位器模式（Service Locator）的形式出现。

DI	DL
Context依赖各事例	各实例依赖context
通过构造函数、setter函数等容易查看依赖关系	依赖关系不容易查看，需要分析调用locator的源码分析依赖关系
装配关系在业务类外的配置文件中	装配关系在业务类中
被动接收依赖对象	主动查询依赖对象

这两种方式的主要区别在于配置方式不同、获得依赖对象的方式不同。

该怎么决定在代码中使用DI还是DL呢？Martin Fowler有话说

So the decision between locator and injector depends on whether that dependency is a problem.

参考连接

https://www.martinfowler.com/bliki/InversionOfControl.html
https://www.martinfowler.com/articles/injection.html
https://en.wikipedia.org/wiki/Inversion_of_control