浅谈 JavaScript 模块化编程

JavaScript本身不是一种模块化语言，设计者在创造JavaScript之初应该也没有想到这么一个脚本语言的作用领域会越来越大。以前一个页面的JS代码再多也不会多到哪儿去，而现在随着越来越多的JavaScript库和框架的出现，Single-page App的流行以及Node.js的迅猛发展，如果我们还不对自己的JS代码进行一些模块化的组织的话，开发过程会越来越困难，运行性能也会越来越低。因此，了解JS模块化编程是非常重要的。

简单的模块

什么是模块？我认为将不同功能的函数放在一起，组成一个能实现某种或某些特定功能的整体就是一个模块，因此这样：

function add(a, b) {
  return a + b;
}

function divide(a, b) {
  return a / b;
}

如此简单的两个函数就可以组成一个模块，这个模块可以进行一些数学运算。

当然没有人会这么写模块。仅仅是从“型”上来看，两个函数分散在全局环境中，这也看不出模块的特点。模块存在于全局变量中，应该提供一个命名空间，成为模块内容的入口。那么我们可以将函数包裹在一个对象中：

var math = {
  add: function(a, b) {
    return a + b;
  },
  divide: function(a, b) {
    return a / b;
  }
}

这样看起来似乎有模块的“型”了。但是这样还不完善，math中的所有成员都是对外暴露的，如果其中有一些变量不希望被修改的话那就有风险了。为了防止世界被破坏，为了维护私有变量不被修改，我们可以使用闭包。

var math = (function() {
  var _flag = 0;

  return {
    add: function(a, b) {
      return a + b;
    },
    divide: function(a, b) {
      return a / b;
    }
  };
})();

外部代码只能访问返回的add和divide方法，内部的_flag变量是不能访问的。关于创建对象的一些方法的解释，可以参考我的另一篇博文，里面有较详细的解释。

利用自执行函数的特点，我们还可以很方便地为模块添加方法：

var math = (function(module) {
  module.subtract = function(a, b) {
    return a - b;
  }
})(math);

模块在全局变量中的名称可能会与其他的模块产生冲突，例如$符号，虽然使用方便，但多个模块可能都会用它作为自己的简写，例如jquery。我们可以在模块的组织代码中用$作为形参，将模块的全名变量作为参数传入，可起到防冲突的效果。

var math = (function($) {
  // 这里的$指的就是Math
})(math);

模块的构建思想便是通过这样的方式逐渐演化而来，下面将通过介绍一些JS模块化编程的标准来展示如何组织，管理和编写模块。

AMD 与 CMD

在JavaScript模块化编程的世界中，有两个规范不得不提，它们分别是AMD和CMD。现在的JS库或框架，凡是模块化的，一般都是遵循了这两个规范其中之一。

AMD（Asynchronous Module Definition）

CommonJS
在说AMD之前，先要提一下CommonJS。CommonJS是为了弥补JavaScript标准库过少的缺点而产生的，由于JS没有模块机制（ES6引入了模块系统，但浏览器全面支持估计还有好几年），CommonJS就帮助JS实现模块的功能。现在很热门的Node.js就是CommonJS规范的一个实现。

CommonJS在模块中定义方法要借助一个全局变量exports，它用来生成当前模块的API：

/* math module */

exports.add = function(a, b) {
  return a + b;
};

要加载模块就要使用CommonJS的一个全局方法require()。加载之前实现的math模块像这样：

var math = require('math');

加载后math变量就是这个模块对象的一个引用，要调用模块中的方法就像调用普通对象的方法一样了：

var math = require('math');
math.add(1, 3);

总之，CommonJS就是一个模块加载器，可以方便地对JavaScript代码进行模块化管理。但它也有缺点，它在设计之初并没有完全为浏览器环境考虑，浏览器环境的特点是所有的资源，不考虑本地缓存的因素，都需要从服务器端加载，加载的速度取决于网络速度，而CommonJS的模块加载过程是同步阻塞的。也就是说如果math模块体积很大，网速又不好的时候，整个程序便会停止，等待模块加载完成。

随着浏览器端JS资源的体积越来越庞大，阻塞给体验带来的不良影响也越来越严重，终于从，在CommonJS社区中有了不同的声音，AMD规范诞生了。

AMD
它的特点便是异步加载，模块的加载不会影响其他代码的运行。所有依赖于某个模块的代码全部移到模块加载语句的回调函数中去。AMD的require()语句接受两个参数：

// require([module], callback)
require(['math'], function(math) {
  math.add(1, 3);
});

在回调函数中，可以通过math变量引用模块。

AMD规范也规定了模块的定义规则，使用define()函数。

define(id?, dependencies?, factory);

它接受三个参数：
id
这是一个可选参数，相当于模块的名字，加载器可通过id名加载对应的模块。如果没有提供id，加载器会将模块文件名作为默认id。

dependencies
可选，接受一个数组参数，传入当前对象依赖的对象id。

factory
回调函数，在依赖模块加载完成后会调用，它的参数是所有依赖模块的引用。回调函数的返回值就是当前对象的导出值。

用AMD规范实现一个简单的模块可以这样：

define('foo', ['math'], function(math) {
  return {
    increase: function(x) {
      return math.add(x, 1);
    }
  };
});

如果省去id和dependencies参数的话，就是一个完全的匿名模块。factory的参数将为默认值require，exports和module加载器将完全通过文件路径的方式加载模块，同时如果有依赖模块的话可通过require方法加载。

define(function(require, exports, module) {
  var math = require('math');

  exports.increase = function(x) {
    return math(x, 1);
  };
});

AMD规范也允许对加载进行一些配置，配置选项不是必须的，但灵活更改配置，会给开发带来一些方便。

baseUrl 以字符串形式规定根目录的路径，以后在加载模块时都会以该路径为标准。在浏览器中，工作目录的路径就是运行脚本的网页所在的路径。

{
  baseUrl: './foo/bar'
}

path 可以指定需加载模块的路径，模块名与路径以键-值对的方式写在对象中。如果一个模块有多个可选地址，可以将这些地址写在一个数组中。

{
  path: {
    'foo': './bar'
  }
}

关于模块路径的设置项还有packages，map。

shim
对于某些没有按照AMD规范编写的模块，比如jQuery，来说，要使它们能被加载器加载，需要用shim方法为其配置一些属性。在main模块中，用require.config()方法：

require.config({
  shim: {
    'jquery': {
      exports: '$'
    },
    'foo': {
      deps: [
        'bar',
        'jquery'
      ],
      exports: 'foo'
    }
  }
});

之后再用加载器加载就可以了。

目前实现了AMD规范的库有很多，比较有名的是Require.js。

CMD（Common Module Definition）

CMD在很多地方和AMD有相似之处，在这里我只说两者的不同点。

首先，CMD规范和CommonJS规范是兼容的，相比AMD，它简单很多。遵循CMD规范的模块，可以在Node.js中运行。

define
与AMD规范不同的是CMD规范中不使用id和deps参数，只保留factory。其中：
1.factory接收对象/字符串时，表明模块的接口就是对象/字符串。

define({ 'foo': 'bar' });

define('My name is classicemi.');

define.cmd
其值为一个空对象，用于判断页面中是否有CMD模块加载器。

if (typeof define === 'function' && define.cmd) {
  // 使用CMD模块加载器编写代码
}

require
此函数同样用于获取模块接口。如需异步加载模块，使用require.async方法。

define(function(require, exports, module) {
  require.async('math', function(math) {
    math.add(1, 2);
  });
});

我们可以发现，require(id)的写法和CommonJS一样是以同步方式加载模块。要像AMD规范一样异步加载模块则使用define.async方法。

exports
此方法用于模块对外提供接口。

define(function(require, exports, module) {
  // 对外提供foo属性
  exports.foo = 'bar';

  // 对外提供add方法
  exports.add = function(a, b) {
    return a + b;
  }
});

提供接口的另一个方法是直接return包含接口键值对的对象：

define(function(require, exports, module) {
  return {
    foo: 'bar',
    add: function(a, b) {
      return a + b;
    }
  }
});

但是注意，不能用exports输出接口对象：

define(function(require, exports, module) {
  exports = {
    foo: 'bar',
    add: function(a, b) {
      return a + b;
    }
  }
});

这样写是错误的！
替代方式是这样写：

define(function(require, exports, module) {
  module.exports = {
    foo: 'bar',
    add: function(a, b) {
      return a + b;
    }
  }
});

之前错误的原因是在factory内部，exports实际上是module.exports的一个引用，直接给exports赋值是不会改变module.exports的值的。

在module对象上，除了有上面提到的exports以外，还有一些别的属性和方法。
module.id
模块的标识。

define('math', [], function(require, exports, module) {
  // module.id 的值为 math
});

module.uri
模块的绝对路径，由模块系统解析得到。

define(function(require, exports, module) {
  console.log(module.uri); // http://xxx.com/path/
});

module.dependencies
值为一个数组，返回本模块的依赖。

Require.js 和 Sea.js

之前在说AMD规范的时候提到了Require.js。它是AMD规范的代表性产品。另一个Sea.js在前端界也是赫赫有名了，CMD规范实际上就是它的产出。它们之间的区别也很能表现AMD和CMD规范之间的区别。

AMD的依赖需要前置书写

define(['foo', 'bar'], function(foo, bar) {
  foo.add(1, 2);
  bar.subtract(3, 4);
});

CMD的依赖就近书写即可，不需要提前声明：
同步式：

define(function(require, exports, module) {
  var foo = require('foo');
  foo.add(1, 2);
  ...
  var bar = require('bar');
  bar.subtract(3, 4);
});

异步式：

define(function(require, exports, module) {
  ...
  require.async('math', function(math) {
    math.add(1, 2);
  });
  ...
});

虽然AMD也可以用和CMD相似的方法，但不是官方推荐的。

之前在介绍CMD的API时，我们可以发现其API职责专一，例如同步加载和异步加载的API都分为require和require.async，而AMD的API比较多功能。

总而言之，引用玉伯的总结：
1. Require.js同时适用于浏览器端和服务器环境的模块加载。Sea.js则专注于浏览器端的模块加载实现。通过Node扩展也可以运行于Node环境中。
2. Require.js -> AMD，Sea.js -> CMD。
3. RequireJS 在尝试让第三方类库修改自身来支持 RequireJS，目前只有少数社区采纳。Sea.js 不强推，采用自主封装的方式来“海纳百川”，目前已有较成熟的封装策略。
4. Sea.js的调试工具比较完备，Require.js调试比较不方便。
5. RequireJS 采取的是在源码中预留接口的形式，插件类型比较单一。Sea.js 采取的是通用事件机制，插件类型更丰富。

怎么看都像是在自夸啊= =，当然它有这个资格

参考文献

1. CommonJS官网
2. 阮一峰博客
3. AMD Github
4. CMD Github
5. Sea.js
6. Require.js

您可能感兴趣的文章：
浅谈模块化的JavaScript
浅谈 JavaScript 模块化编程
浅谈Python深浅拷贝以及应用场景
浅谈HTML5和HTML4之间的不同
前端模块化杂谈
浅谈RBAC中几种常见的控制权限模型
asp.net 浅谈MVC 架构模式（上）
浅谈php中线程安全和非线程安全的不同
PHP——thinkphp5的详解介绍与使用
浅谈对PHP单例模式的理解以及示例代码