咱们再一次被计算机的名词、概念笼罩。html
Backbone、Emberjs、Spinejs、Batmanjs 等MVC框架侵袭而来。
CommonJS、AMD、NodeJS、RequireJS、SeaJS、Curljs 等模块化的JavaScript概念及库扑面而来。前端
模块化JavaScript的概念尤其突出,彷佛有赶超07年Ajax风潮之趋势。node
写函数(过程式)
2005年之前,JavaScript没人重视,只做为表单验证等少许应用。那时一个网页上写不了几行JS代码,1000行算很复杂了。这时组织代码的方式是过程式,几十行的代码甚至连一个函数都不用写。稍多的须要提取抽象出一个函数,更复杂一些则须要更多函数,函数间互相调用。git
写类(面向对象)
2006年,Ajax席卷全球。JavaScript被重视了,愈来愈多的后端逻辑放到了前端。网页中的JS代码量急剧增长。这时写函数方式组织大量代码显得力不从心。有时调试一个小功能,从一个函数可能会跳到第N个函数去。这时写类的方式出现了,Prototype 率先流行开来。用它组织代码,写出的都是一个个类,每一个类都是Class.create建立的。又有YUI、Ext等重量级框架。虽然它们的写类方式各不一样,但它们的设计思路却都是要知足大量JavaScript代码的开发。程序员
写模块(如今,将来?)
2009年,Nodejs诞生!这个服务器端的JavaScript采用模块化的写法很快征服了浏览器端的JSer。牛人们纷纷仿效,各类写模块的规范也是层出不穷。CommonJS想统一先后端的写法,AMD则认为本身是适合浏览器端的。好吧,不管写模块的风格是啥样,写模块化的JavaScript却已开始流行了。你,准备好了吗?github
模块化的JavaScript是神马? 这是咱们发明了又一个银弹吗?不管是啥,就当学习吧。至于适不适合项目中使用,各自斟酌。json
写到这也没说什么是“模块”。其实在计算机领域,模块化的概念被推崇了近四十年。软件整体结构体现模块化思想,即把软件划分为一些独立命名的部件,每一个部件称为一个模块,当把全部模块组装在一块儿的时候,即可得到问题的一个解。模块化以分治法为依据,可是否意味着咱们把软件无限制的细分下去?事实上当分割过细,模块总数增多,每一个模块的成本确实减小了,但模块接口所需代价随之增长。后端
要确保模块的合理分割则须了解信息隐藏,内聚度及耦合度。设计模式
信息隐藏
模块应设计的使其所包含的信息(过程和数据)对于那些不须要用到它的模块不可见。每一个模块只完成一个独立的功能,而后提供该功能的接口。模块间经过接口访问。JavaScript中能够用函数去隐藏,封装,然后返回接口对象。以下是一个提供事件管理的模块event。跨域
1
2
3
4
5
6
7
8
|
Event = function() {
// do more
return {
bind: function() {},
unbind: function() {},
trigger: function() {}
};
}();
|
函数内为了实现想要的接口bind、unbind、trigger可能须要写不少不少代码,但这些代码(过程和数据)对于其它模块来讲没必要公开,外部只要能访问接口bind,unbind,trigger便可。
信息隐藏对于模块设计好处十分明显,它不只支持模块的并行开发,并且还可减小测试或后期维护工做量。如往后要修改代码,模块的隐藏部分可随意更改,前提是接口不变。如事件模块开始实现时为了兼容旧版本IE及标准浏览器,写了不少IE Special代码,有一天旧版本IE消失了(猴年马月),只需从容删去便可。
内聚度
内聚是来自结构化设计的一个概念,简单说内聚测量了单个模块内各个元素的联系程度。最不但愿出现的内聚就是偶然性内聚,即将彻底无关的抽象塞进同一个模块或类中。最但愿出现的内聚是功能性内聚,即一个模块或类的各元素一同工做,提供某种清晰界定的行为。
内聚度指模块内部实现,它是信息隐藏和局部化概念的天然扩展,它标志着一个模块内部各成分彼此结合的紧密程度。好处也很明显,当把相关的任务分组后去阅读就容易多了。设计时应该尽量的提升模块内聚度,从而得到较高的模块独立性。
耦合度
耦合也是来自结构化设计,Stevens、Myers和Constantine将耦合定义为「一个模块与另外一个模块之间创建起的关联强度的测量。强耦合使系统变得复杂,由于若是模块与其它模块高度相连,它就难以独立的被理解、变化和修正」
内聚度是指特定模块内部实现的一种度量,耦合度则是指模块之间的关联程度的度量。耦合度取决于模块之间接口的复杂性,进入或调用模块的位置等。与内聚度相反,在设计时应尽可能追求松散耦合的系统。
在JavaScript模块究竟是什么,能用代码具体展示一下吗?其实上面已经写了一段事件模块代码
这能表明“模块”吗?这就是一个JS对象啊,觉得有多么深奥。
是的,JavaScript中模块多数时候被实现为一个对象。这么看来,多数时候咱们都写过“模块”(但没有在整个项目中应用模块化思想)。或许每一个人写模块的方式(风格)还不一样。好比上面的事件模块是一个匿名函数执行,匿名函数中封装了不少代码,最后经过return返回给Event变量,这个Event就是事件模块的接口。
又如jQuery,它也是一个匿名函数执行,但它并不返回接口对象。而是将本身暴露给window对象。
1
2
3
4
5
|
(function(window){
// ..
// exports
window.jQuery = window.$ = jQuery;
})(window);
|
再如SeaJS,它一开始就将接口公开了
1
2
3
4
|
/**
* Base namespace for the framework.
*/
this.seajs = { _seajs: this.seajs };
|
后续是不少的匿名函数执行给变量seajs添加不少工具方法。注意,这里的this在浏览器环境指window对象,若是是定位在浏览器中,这个this也能够去掉。就象Ext。
1
2
3
4
5
6
7
|
Ext = {
/**
* The version of the framework
* @type String
*/
version : '3.1.0'
};
|
咱们已经看到了四种方式写模块(把jQuery,SeaJS,Ext当作模块,呃很大的模块)。哪种更好呢? 哪种更适合在浏览器端呢?纯从代码风格上说,是萝卜白菜各有所爱。只要咱们运用了“模块化”的思想来开发就好了。
但若是有一种统一的语法格式来写模块岂不是更好,就不会出现各用各的风格来写模块而使代码乱糟糟。
这就是目前的现状,开发者强烈须要一种统一的风格来写模块(最好是语言内置了)。这时一些组织出现了,最具表明的如CommonJS,AMD。此外ECMAScript也开始着手模块的标准化写法。
不管它们提供什么样的写法,咱们须要的仅仅是:
服务器端的JSer是幸运的,它有Node.js,Node.js遵循了一个称为CommonJS的规范。CommonJS其中就有对写模块的标准化。固然模块化只是其中的一部分而已。
具体来讲Node.js实现了:
在模块化方面,它实现了Modules/1.0(已经更新到1.1.1),如下是node中是写模块的一个示例。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
MATH.JS
exports.add = function() {
var sum = 0, i = 0, args = arguments, l = args.length;
while (i < l) {
sum += args[i++];
}
return sum;
};
INCREMENT.JS
var add = require('math').add;
exports.increment = function(val) {
return add(val, 1);
};
MAIN.JS
var inc = require('increment').increment;
var a = 1;
inc(a); // 2
|
这就写了一个math、increment、main模块。math提供了add方法来实现数字相加。increment模块依赖于math模块,它提供increment方法实现相加。main获取到increment方法,执行相加操做。
以上代码示例能够看到:
CommonJS module基本要求以下:
Modules/1.1较1.0仅增长了标示符module,require函数增长了main和paths属性。而仔细比对1.1与1.1.1后发现除了格式调整了下几乎没有变化。
前面提到Node.js有一套简洁的格式写模块,它遵循的就是 Moudles。
浏览器里的JavaScript呢? 尽管语言自己暂不支持模块(ES6打算支持),但能够用现有的API包装一个写法出来。
毫无疑问,首先想到的是Node.js的Modules格式,它是最好的效仿对象。由于先后端有一个统一的方式写JS模块岂不乐哉!
但一开始就碰到一些难题:
服务器端JS模块文件就在本地,浏览器端则须要经过网络请求。
服务器端能够很容易的实现同步或异步请求模块,浏览器端则问题多多。
以下。
1
2
3
4
|
var event = require("event");
event.bind(el, 'click', function() {
// todo
});
|
这段代码中require若是是异步执行的,则event.bind的执行有可能会出错。
那实现同步的require不就好了吗?的确可使用 XHR 实现同步载入模块JS文件。但XHR的缺点也是明显的,它不能跨域,这点让人很难接受,由于有些场景须要模块部署在不一样的服务器。
那只能经过script tag来实现模块加载了!但script tag默认就是异步的,要实现Node.js的如出一辙风格(Modules)很难,几乎是不可能。
这时,“救世主”出现了:Modules/Wrappings ,顾名思义包裹的模块。该规范约定以下:
描述有拗口,代码却很简单,使用了一个function包裹模块(Node.js模块则无需包裹)。
1
2
3
4
5
6
7
8
9
10
11
|
一个基本的模块定义
module.declare(function(require, exports, module)
{
exports.foo = "bar";
});
直接使用对象做为模块
module.declare(
{
foo: "bar"
});
|
Modules/Wrappings的出现使得浏览器中实现它变得可能,包裹的函数做为回调。即便用script tag做为模块加载器,script彻底下载后去回调,回调中进行模块定义。
好了,截止目前咱们已经看到了两种风格的模块定义:Modules 和 Modules/Wrappings。
CommonJS Modules有1.0、1.一、1.1.1三个版本:
Node.js、SproutCore实现了 Modules 1.0
SeaJS、AvocadoDB、CouchDB等实现了Modules 1.1.1
SeaJS、FlyScript实现了Modules/Wrappings
注意:
SeaJS未实现所有的 Modules 1.1.1,如require函数的main,paths属性在SeaJS中没有。但SeaJS给require添加了async、resolve、load、constructor。
SeaJS没有使用 Modules/Wrappings 中的module.declare定义模块,而是使用define函数(看起来象AMD中的define,实则否则)。
前面提到,为实现与Node.js相同方式的模块写法,大牛们作了不少努力。
但浏览器环境不一样于服务器端,它的模块有一个HTTP请求过程(而Node.js的模块文件就在本地),这个请求过程多数使用script tag,script 默认的异步性致使很难实现与Node.js如出一辙的模块格式。
Modules/Wrappings 使得实现变为现实。虽然和Node.js的模块写法不彻底一致,但也有不少类似之处,使得熟悉Node.js的程序员有一些亲切感。
但Node.js终究是服务器端的JavaScript,没有必要把这些条条框框放到浏览器JavaScript环境中。
这时AMD 诞生了,它的全称为异步模块定义。从名称上看便知它是适合script tag的。也能够说AMD是专门为浏览器中JavaScript环境设计的规范。它吸收了CommonJS的一些优势,但又不照搬它的格式。开始AMD做为CommonJS的transport format 存在,因没法与CommonJS开发者达成一致而独立出来。它有本身的wiki 和讨论组 。
AMD设计出一个简洁的写模块API:
define(id?, dependencies?, factory);
其中:
id: 模块标识,能够省略。
dependencies: 所依赖的模块,能够省略。
factory: 模块的实现,或者一个JavaScript对象。
特别指出,id遵循CommonJS Module Identifiers 。dependencies元素的顺序和factory参数一一对应。
如下是使用AMD模式开发的简单三层结构(基础库/UI层/应用层),用于展现模块的五种写法:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
BASE.JS
define(function() {
return {
mix: function(source, target) {
}
};
});
UI.JS
define(['base'], function(base) {
return {
show: function() {
// todo with module base
}
}
});
PAGE.JS
define(['data', 'ui'], function(data, ui) {
// init here
});
DATA.JS
define({
users: [],
members: []
});
|
以上同时演示了define的前三种用法。细心的会发现,还有两种没有出现:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
具名模块
define('index', ['data','base'], function(data, base) {
// todo
});
包装模块
define(function(require, exports, module) {
var base = require('base');
exports.show = function() {
// todo with module base
}
});
|
若是不考虑多了一层函数外,格式和Node.js是同样的:使用require获取依赖模块,使用exports导出API。
除了define外,AMD还保留一个关键字require。require 做为规范保留的全局标识符,能够实现为 module loader,也能够不实现。
目前,实现AMD的库有RequireJS 、curl 、Dojo 、bdLoad、JSLocalnet 、Nodules 等。也有不少库支持AMD规范,即将本身做为一个模块存在,如MooTools 、jQuery 、qwery 、bonzo 甚至还有 firebug 。
UMD是AMD 和CommonJS的糅合,前面花了很长的篇幅介绍了两大类模块规范,CommonJS(Modules/Modules/Wrappings)及AMD。
咱们知道Modules/Wrappings是出于对Node.js模块格式的偏好而包装下使其在浏览器中得以实现。而Modules/Wrappings的格式经过某些工具(如r.js)也能运行在Node.js中。事实上,这两种格式同时有效且都被普遍使用。
AMD以浏览器为第一(browser-first)的原则发展,选择异步加载模块。它的模块支持对象(objects)、函数(functions)、构造器(constructors)、字符串(strings)、JSON等各类类型的模块。所以在浏览器中它很是灵活。
CommonJS module以服务器端为第一(server-first)的原则发展,选择同步加载模块。它的模块是无需包装的(unwrapped modules)且贴近于ES.next/Harmony的模块格式。但它仅支持对象类型(objects)模块。这迫使一些人又想出另外一个更通用格式 UMD(Universal Module Definition)。但愿提供一个先后端跨平台的解决方案。
UMD的实现很简单,先判断是否支持Node.js模块格式(exports是否存在),存在则使用Node.js模块格式。接着判断是否支持AMD(define是否存在),存在则使用AMD方式加载模块。前两个都不存在,则将模块公开到全局(window或global)。下面是一个示例:
下面是一个示例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
EVENTUTIL.JS
(function (root, factory) {
if (typeof exports === 'object') {
module.exports = factory();
} else if (typeof define === 'function' && define.amd) {
define(factory);
} else {
root.eventUtil = factory();
}
})(this, function() {
// module
return {
addEvent: function(el, type, handle) {
//...
},
removeEvent: function(el, type, handle) {
},
};
});
|
虽然UMD八字尚未一撇,有些开源库却开始支持UMD了,如大名鼎鼎的《JavaScript设计模式》做者Dustin Diaz开发的qwery。代码以下:
1
2
3
4
5
6
7
8
9
|
!function(name,definition){
if(typeof module != 'function') module.exports = definition()
else if (typeof define == 'function' && typeof define.amd == 'object') define(definition)
else this(name) = definition()
}('query',function(){
var doc =document
, html = doc.documentElement
// ...
})
|
ECMAScript的下一个版本Harmony已经考虑到了模块化的需求。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
使用
module关键字来定义一个模块
module math {
export function sum(x, y) {
return x + y;
}
export var pi = 3.141593;
}
使用
import关键字来加载外部模块
// we can import in script code, not just inside a module
import {sum, pi} from math;
alert("2π = " + sum(pi, pi));
引入全部
API
// import everything
import * from math;
alert("2π = " + sum(pi, pi));
局部重命名
import { draw: drawShape } from shape;
import { draw: drawGun } from cowboy;
嵌套模块
module widgets {
export module button { ... }
export module alert { ... }
export module textarea { ... }
...
}
import { messageBox, confirmDialog } from widgets.alert;
…
从服务器上请求的模块
<script type=”harmony”>
// loading from a URL
module JSON at 'http://json.org/modules/json2.js';
alert(JSON.stringify({'hi': ‘world'}));
动态载入一个模块
Loader.load('http://json.org/modules/json2.js', function(JSON) {
alert(JSON.stringify([0, {a: true}]));
});
|
ES6 modules还须要很长时间来规范化,可谓任重而道远。且它有个问题,即新的语法关键字不能向下兼容(如低版本IE浏览器)。