拥抱模块化的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消失了(猴年马月),只需从容删去即可。
内聚度
内聚度指模块内部实现,它是信息隐藏和局部化概念的自然扩展,它标志着一个模块内部各成分彼此结合的紧密程度。好处也很明显,当把相关的任务分组后去阅读就容易多了。
设计时应该尽可能的提高模块内聚度,从而获得较高的模块独立性。
耦合度
内聚度是指特定模块内部实现的一种度量,耦合度则是指模块之间的关联程度的度量。耦合度取决于模块之间接口的复杂性,进入或调用模块的位置等。与内聚度相反,在设计时应尽量追求松散耦合的系统。