擁抱模塊化的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。

函數內為了實現想要的接口bind、unbind、trigger可能需要寫很多很多代碼,但這些代碼(過程和數據)對於其它模塊來說不必公開,外部只要能訪問接口bind,unbind,trigger即可。
信息隱藏對於模塊設計好處十分明顯,它不僅支持模塊的並行開發,而且還可減少測試或后期維護工作量。如日后要修改代碼,模塊的隱藏部分可隨意更改,前提是接口不變。如事件模塊開始實現時為了兼容舊版本IE及標准瀏覽器,寫了很多IE Special代碼,有一天舊版本IE消失了(猴年馬月),只需從容刪去即可。

內聚度
內聚是來自結構化設計的一個概念,簡單說內聚測量了單個模塊內各個元素的聯系程度。最不希望出現的內聚就是偶然性內聚,即將完全無關的抽象塞進同一個模塊或類中。最希望出現的內聚是功能性內聚,即一個模塊或類的各元素一同工作,提供某種清晰界定的行為。
內聚度指模塊內部實現,它是信息隱藏和局部化概念的自然擴展,它標志着一個模塊內部各成分彼此結合的緊密程度。好處也很明顯,當把相關的任務分組后去閱讀就容易多了。設計時應該盡可能的提高模塊內聚度,從而獲得較高的模塊獨立性。

耦合度
耦合也是來自結構化設計,Stevens、Myers和Constantine將耦合定義為「一個模塊與另一個模塊之間建立起的關聯強度的測量。強耦合使系統變得復雜,因為如果模塊與其它模塊高度相連,它就難以獨立的被理解、變化和修正」
內聚度是指特定模塊內部實現的一種度量,耦合度則是指模塊之間的關聯程度的度量。耦合度取決於模塊之間接口的復雜性,進入或調用模塊的位置等。與內聚度相反,在設計時應盡量追求松散耦合的系統。

JavaScript中模塊“寫法”

在JavaScript模塊到底是什么,能用代碼具體展現一下嗎?其實上面已經寫了一段事件模塊代碼

這能代表“模塊”嗎?這就是一個JS對象啊,以為有多么深奧。

是的,JavaScript中模塊多數時候被實現為一個對象。這么看來,多數時候我們都寫過“模塊”(但沒有在整個項目中應用模塊化思想)。或許每個人寫模塊的方式(風格)還不同。比如上面的事件模塊是一個匿名函數執行,匿名函數中封裝了很多代碼,最后通過return返回給Event變量,這個Event就是事件模塊的接口。

又如jQuery,它也是一個匿名函數執行,但它並不返回接口對象。而是將自己暴露給window對象。

再如SeaJS,它一開始就將接口公開了

后續是很多的匿名函數執行給變量seajs添加很多工具方法。注意,這里的this在瀏覽器環境指window對象,如果是定位在瀏覽器中,這個this也可以去掉。就象Ext。

我們已經看到了四種方式寫模塊(把jQuery,SeaJS,Ext看成模塊,呃很大的模塊)。哪一種更好呢? 哪一種更適合在瀏覽器端呢?純從代碼風格上說,是蘿卜白菜各有所愛。只要我們運用了“模塊化”的思想來開發就行了。

但如果有一種統一的語法格式來寫模塊豈不是更好,就不會出現各用各的風格來寫模塊而使代碼亂糟糟。

這就是目前的現狀,開發者強烈需要一種統一的風格來寫模塊(最好是語言內置了)。這時一些組織出現了,最具代表的如CommonJS,AMD。此外ECMAScript也開始着手模塊的標准化寫法。

無論它們提供什么樣的寫法,我們需要的僅僅是:

  • 將一些零散代碼封裝成一個有用的單元(encapsulate)
  • 導出模塊的接口API(exports)
  • 方便友好引用其它模塊(dependency)

服務器端的JSer是幸運的,它有Node.js,Node.js遵循了一個稱為CommonJS的規范。CommonJS其中就有對寫模塊的標准化。當然模塊化只是其中的一部分而已。

具體來說Node.js實現了:

在模塊化方面,它實現了Modules/1.0(已經更新到1.1.1),以下是node中是寫模塊的一個示例。

這就寫了一個math、increment、main模塊。math提供了add方法來實現數字相加。increment模塊依賴於math模塊,它提供increment方法實現相加。main獲取到increment方法,執行相加操作。

以上代碼示例可以看到:

  • node要求一個js文件對應一個模塊。可以把該文件中的代碼想象成是包在一個匿名函數中,所有代碼都在匿名函數中,其它模塊不可訪問除exports外的私有變量
  • 使用exports導出API
  • 使用require加載其它模塊

CommonJS module基本要求如下:

  • 標示符require,為一個函數,它僅有一個參數為字符串,該字符串須遵守Module Identifiers的6點規定
  • require方法返回指定的模塊API
  • 如果存在依賴的其它模塊,那么依次加載
  • require不能返回,則拋異常
  • 僅能使用標示符exports導出API

Modules/1.1較1.0僅增加了標示符module,require函數增加了main和paths屬性。而仔細比對1.1與1.1.1后發現除了格式調整了下幾乎沒有變化。

Node.js模塊格式在瀏覽器中的嘗試

前面提到Node.js有一套簡潔的格式寫模塊,它遵循的就是 Moudles。
瀏覽器里的JavaScript呢? 盡管語言本身暫不支持模塊(ES6打算支持),但可以用現有的API包裝一個寫法出來。
毫無疑問,首先想到的是Node.js的Modules格式,它是最好的效仿對象。因為前后端有一個統一的方式寫JS模塊豈不樂哉!
但一開始就碰到一些難題:
服務器端JS模塊文件就在本地,瀏覽器端則需要通過網絡請求。
服務器端可以很容易的實現同步或異步請求模塊,瀏覽器端則問題多多。
如下。

這段代碼中require如果是異步執行的,則event.bind的執行有可能會出錯。
那實現同步的require不就行了嗎?的確可以使用 XHR 實現同步載入模塊JS文件。但XHR的缺點也是明顯的,它不能跨域,這點讓人很難接受,因為有些場景需要模塊部署在不同的服務器。
那只能通過script tag來實現模塊加載了!但script tag默認就是異步的,要實現Node.js的一模一樣風格(Modules)很難,幾乎是不可能。

這時,“救世主”出現了:Modules/Wrappings ,顧名思義包裹的模塊。該規范約定如下:

  • 定義模塊用module變量,它有一個方法declare。
  • declare接受一個函數類型的參數,如稱為factory。
  • factory有三個參數分別為require、exports、module。
  • factory使用返回值和exports導出API。
  • factory如果是對象類型,則將該對象作為模塊輸出。

描述有拗口,代碼卻很簡單,使用了一個function包裹模塊(Node.js模塊則無需包裹)。

Modules/Wrappings的出現使得瀏覽器中實現它變得可能,包裹的函數作為回調。即使用script tag作為模塊加載器,script完全下載后去回調,回調中進行模塊定義。

好了,截止目前我們已經看到了兩種風格的模塊定義:Modules 和 Modules/Wrappings。

CommonJS Modules有1.0、1.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,實則不然)。

AMD:瀏覽器中的模塊規范

前面提到,為實現與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. 定義無依賴的模塊(base.js)
  2. 定義有依賴的模塊(ui.js,page.js)
  3. 定義數據對象模塊(data.js)
  4. 具名模塊
  5. 包裝模塊

 

以上同時演示了define的前三種用法。細心的會發現,還有兩種沒有出現:

如果不考慮多了一層函數外,格式和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:各種模塊格式的糅合

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)。下面是一個示例:

下面是一個示例:

雖然UMD八字還沒有一撇,有些開源庫卻開始支持UMD了,如大名鼎鼎的《JavaScript設計模式》作者Dustin Diaz開發的qwery。代碼如下:

 

ECMAScript6:未來的JS模塊化

ECMAScript的下一個版本Harmony已經考慮到了模塊化的需求。

ES6 modules還需要很長時間來規范化,可謂任重而道遠。且它有個問題,即新的語法關鍵字不能向下兼容(如低版本IE瀏覽器)。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM