浅谈控制反转(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
浅谈控制反转(IoC)_第1张图片 浅谈控制反转(IoC)_第2张图片
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

你可能感兴趣的:(编码设计,开发语言,设计模式)