擁抱模組化的JavaScript_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消失了（猴年馬月），只需從容刪去即可。

內聚度
內聚度指模組內部實現，它是資訊隱藏和局部化概念的自然擴充，它標誌著一個模組內部各成分彼此結合的緊密程度。好處也很明顯，當把相關的任務分組後去閱讀就容易多了。
設計時應該儘可能的提高模組內聚度，從而獲得較高的模組獨立性。

耦合度
內聚度是指特定模組內部實現的一種度量，耦合度則是指模組之間的關聯程度的度量。耦合度取決於模組之間介面的複雜性，進入或調用模組的位置等。與內聚度相反，在設計時應盡量追求鬆散耦合的系統。