浅谈控制反转（IoC）

2023-10-29

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

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)