从前端中的IOC理念理解koa中的app.use()

忙里偷闲，打开平时关注的前端相关的网站，浏览最近最新的前端动态。佼佼者，平凡的我做不到，但还是要争取不做落后者。

前端中的IoC理念，看到这个标题就被吸引了。IoC 理念，不认识呢，点击去一看，果然没让我失望，原文结合案例把概念诠释的很清楚。原来 Ioc 是 控制反转 或 依赖倒置。

控制反转、依赖倒置、依赖注入 这三个名词，我倒是很耳熟了，毕竟在大学学 java web 课程的时候接触过，记得当时还很认真的学了并做了笔记。时间真是遗忘的罪魁祸首，现在就只记得名词，而全然忘了概念。

什么是 IoC ?

IoC 的全称是Inversion of Control，翻译为 控制反转 或 依赖倒置，主要包含了三个准则：

高层次的模块不应该依赖于底层次的模块，它们都应该依赖于抽象
抽象不应该依赖于具体实现，具体实现应该依赖于抽象
面向接口编程，而不要面向实现编程

举例

假设需要构建一款应用叫 App，它包含一个路由模块 Router 和一个页面监控模块 Track，一开始可能会这么实现：

// app.js

import Router from './modules/Router';

import Track from './modules/Track';

class App {

    constructor(options) {

        this.options = options;

        this.router = new Router();

        this.track = new Track();

        this.init();

    }

    init() {

        window.addEventListener('DOMContentLoaded', () => {

            this.router.to('home');

            this.track.tracking();

            this.options.onReady();

        });

    }

}

// index.js

import App from 'path/to/App';

new App({

    onReady() {

        // do something here...

    },

});

看起来没什么问题，但是实际应用中需求是非常多变的，可能需要给路由新增功能（比如实现 history 模式）或者更新配置（启用 history, new Router({ mode: 'history' })）。这就不得不在 App 内部去修改这两个模块，而对于之前测试通过了的 App 来说，也必须重新测试。

很明显，这不是一个好的应用结构，高层次的模块 App 依赖了两个低层次的模块 Router 和 Track，对低层次模块的修改都会影响高层次的模块 App。那么如何解决这个问题呢，解决方案就是接下来要讲述的依赖注入（Dependency Injection）。

什么是依赖注入？

所谓的依赖注入，简单来说就是把高层模块所依赖的模块通过传参的方式把依赖「注入」到模块内部，上面的代码可以通过依赖注入的方式最终改造成如下方式：

class App {

    static modules = []

    constructor(options) {

        this.options = options;

        this.init();

    }

    init() {

        window.addEventListener('DOMContentLoaded', () => {

            this.initModules();

            this.options.onReady(this);

        });

    }

    static use(module) {

        Array.isArray(module) ? module.map(item => App.use(item)) : App.modules.push(module);

    }

    initModules() {

        App.modules.map(module => module.init && typeof module.init == 'function' && module.init(this));

    }

}

经过改造后 App 内已经没有「具体实现」了，看不到任何业务代码了，那么如何使用 App 来管理我们的依赖呢：

// modules/Router.js

import Router from 'path/to/Router';

export default {

    init(app) {

        app.router = new Router(app.options.router);

        app.router.to('home');

    }

};

// modules/Track.js

import Track from 'path/to/Track';

export default {

    init(app) {

        app.track = new Track(app.options.track);

        app.track.tracking();

    }

};

// index.js

import App from 'path/to/App';

import Router from './modules/Router';

import Track from './modules/Track';

App.use([Router, Track]);

new App({

    router: {

        mode: 'history',

    },

    track: {

        // ...

    },

    onReady(app) {

        // app.options ...

    },

});

可以发现 App 模块在使用上也非常的方便，通过 App.use() 方法来「注入」依赖，在 ./modules/some-module.js 中按照一定的「约定」去初始化相关配置即可。

要实现一个可以被 App.use() 的模块，就必须满足两个约定：

模块必须包含 init 属性
init 必须是一个函数

这其实就是 IoC 思想中对面向接口编程而不要面向实现编程这一准则的很好的体现。App 不关心模块具体实现了什么，只要满足对接口init 的约定就可以了。

在理解了本文的后，再回首看 koa 中的 app.use()，理解起来就没那么难了。

koa 中的 app.use()

koa 的源码文件中关于 constructor 的代码如下：

  constructor() {

    super();

    this.proxy = false;

    this.middleware = [];

    this.subdomainOffset = 2;

    this.env = process.env.NODE_ENV || 'development';

    this.context = Object.create(context);

    this.request = Object.create(request);

    this.response = Object.create(response);

    if (util.inspect.custom) {

      this[util.inspect.custom] = this.inspect;

    }

  }

koa 的源码文件中关于 use 的代码如下：

  use(fn) {

    if (typeof fn !== 'function') throw new TypeError('middleware must be a function!');

    if (isGeneratorFunction(fn)) {

      deprecate('Support for generators will be removed in v3. ' +

                'See the documentation for examples of how to convert old middleware ' +

                'https://github.com/koajs/koa/blob/master/docs/migration.md');

      fn = convert(fn);

    }

    debug('use %s', fn._name || fn.name || '-');

    this.middleware.push(fn);

    return this;

  }

可以看到，可上面的案例很相似，只不过再没有init方法，而是直接调用方法。

而实际使用的时候，是这样的：

const Koa = require('koa')

const app = new Koa()

const m1 = require('./middleware/koa-m1') // 模拟的中间件

app.use(m1())

// 中间件

function m1 (ctx) {

  global.console.log('m1', ctx.path)

}

module.exports = function () {

  return async function (ctx, next) {

    global.console.log('m1 start')

    m1(ctx)

    await next()

    global.console.log('m1 end')

  }

}

总结：IoC 的理念，很值得编程借鉴。刚接触前端时，只知道html、css、JavaScript。而现在发现难的地方，很多都是借鉴了后端的编程思想。比如设计模式，SSR(其实本质应该就是JSP)。IoC 的理念，我想最初的实现应该也是后端。

最后深入了解：

关于 Ioc 理念，可以再仔细的去阅读原文：前端中的IoC理念
深入浅出 Koa
深入浅出 Koa2