拥抱模块化的JavaScript

我们再一次被计算机的名词，概念笼罩。
backbone、emberjs、spinejs、batmanjs 等MVC框架侵袭而来。
CommonJS、AMD、NodeJS、RequireJS、SeaJS、curljs等模块化的JavaScript扑面而来。
模块化JavaScript的概念尤为强烈，似乎有赶超07年Ajax风潮之趋势。
一、写函数（过程式）
2005年以前，JavaScript没人重视，只作为表单验证等少量应用。那时一个网页上写不了几行JS代码，1000行算很复杂了。这时组织代码的方式是过程时，几十行的代码甚至连一个函数都不用写。稍多的需要提取抽象出一个函数，更复杂一些则需要更多函数，函数间互相调用。


二、写类（面向对象）
2006年，Ajax席卷全球。JavaScript被重视了，越来越多的后端逻辑放到了前端。网页中的JS代码量急剧增加。这时写函数方式组织大量代码显得力不从心。有时调试一个小功能，从一个函数可能会跳到第N个函数去。这时写类的方式出现了，Prototype 率先流行开来。用它组织代码，写出的都是一个个类，每个类都是Class.create创建的。又有YUI、Ext等重量级框架。虽然它们的写类方式各不同，但它们的设计思路却都是要满足大量JavaScript代码的开发。

三、写模块（现在，未来？）
2009年，Nodejs诞生！这个服务器端的JavaScript采用模块化的写法很快征服了浏览器端的JSer。牛人们纷纷仿效，各种写模块的规范也是层出不穷。CommonJS想统一前后端的写法，AMD则认为自己是适合浏览器端的。好吧，无论写模块的风格是啥样，写模块化的JavaScript却已开始流行了。准备好了吗？（呃具煽动性）

呵，模块化的JavaScript是啥？ 这是我们发明了又一个银弹吗？无论是啥，就当学习吧。至于适不适合项目中使用，各自斟酌。

写到这也没说什么是“模块”。其实在计算机领域，模块化的概念被推崇了近四十年。软件总体结构体现模块化思想，即把软件划分为一些独立命名的部件，每个部件称为一个模块，当把所有模块组装在一起的时候，便可获得问题的一个解。

模块化以分治法为依据，但是否意味着我们把软件无限制的细分下去。事实上当分割过细，模块总数增多，每个模块的成本确实减少了，但模块接口所需代价随之增加。要确保模块的合理分割则须了解信息隐藏，内聚度及耦合度。

信息隐藏
模块应设计的使其所包含的信息（过程和数据）对于那些不需要用到它的模块不可见。每个模块只完成一个独立的功能，然后提供该功能的接口。模块间通过接口访问。JavaScript中可以用函数去隐藏，封装，而后返回接口对象。如下是一个提供事件管理的模块event。

代码如下：

event = function() { 
// do more 
return { 
bind: function() {}, 
unbind: function() {}, 
trigger: function() {} 
}; 
}();

函数内为了实现想要的接口bind、unbind、trigger可能需要写很多很多代码，但这些代码（过程和数据）对于其它模块来说不必公开，外部只要能访问接口bind，unbind，trigger即可。

信息隐藏对于模块设计好处十分明显，它不仅支持模块的并行开发，而且还可减少测试或后期维护工作量。如日后要修改代码，模块的隐藏部分可随意更改，前提是接口不变。如事件模块开始实现时为了兼容旧版本IE及标准浏览器，写了很多IE Special代码，有一天旧版本IE消失了（猴年马月），只需从容删去即可。

内聚度
内聚度指模块内部实现，它是信息隐藏和局部化概念的自然扩展，它标志着一个模块内部各成分彼此结合的紧密程度。好处也很明显，当把相关的任务分组后去阅读就容易多了。
设计时应该尽可能的提高模块内聚度，从而获得较高的模块独立性。

耦合度
内聚度是指特定模块内部实现的一种度量，耦合度则是指模块之间的关联程度的度量。耦合度取决于模块之间接口的复杂性，进入或调用模块的位置等。与内聚度相反，在设计时应尽量追求松散耦合的系统。