JavaScript模塊化開發(fā)一瞥

1、對于那些初學(xué)JavaScript、同時又正用它構(gòu)建大型應(yīng)用程序的開發(fā)者而言，必須面對的首要挑戰(zhàn)是，該如何組織代碼。盡管起初通過在標(biāo)記之間嵌入數(shù)百行代碼就能跑起來，不過很快代碼會變得一塌糊涂。其中的難點在于，對于組織我們的代碼，JavaScript并未提供任何明顯幫助。從字面上看，C#有using,Java有import而JavaScript一無所有。這就迫使JavaScript作者去嘗試各種不同約定(conventions),并用我們擁有的這種語言創(chuàng)建了一些實踐方法來組織大型JavaScript應(yīng)用程序。形成現(xiàn)代JavaScript基礎(chǔ)的那些模式、工具及實踐必將來自語言本身以外的實現(xiàn)Rebec

2、caMurphy模塊模式(TheModulePattern)解決此問題使用最為廣泛的方法是模塊模式(ModulePattern)。我嘗試在下面解釋一個基本示例，并談?wù)撍囊恍傩?。對于各種不同方法更好的描述和夢幻般的運行，請參閱BenCherry的帖子JavaScriptModulePattern:In-Depth(深入理解JavaScript模塊模式)。(function(lab49)functionprivateAdder(n1,n2)returnn1+n2;lab49.add=function(n1,n2)returnprivateAdder(n1,n2);/原文代碼有誤，已修正。;)(

3、window.lab49=window.lab49|);上面的示例中，我們只使用一些來自語言本身的基本功能，就創(chuàng)建了曾在C#和Java等語言中見過的類似結(jié)構(gòu)。隔離(Isolation)你會注意到這段代碼包在一個立即調(diào)用的函數(shù)里(查看最后一行)。在瀏覽器中，默認(rèn)情況下會在全局范圍(globalscope)級別上對JavaScript文件進(jìn)行評估(evaluated),因此在我們在文件內(nèi)聲明的任何內(nèi)容都是隨處可用的。想象一下，如果在lib1.js中有句varname=.,而lib2.js中有另一句varname=.。那么第二個var語句會替掉第一句的值這可不太妙。然而，由于JavaScript擁有

4、函數(shù)作用域(functionscoping)級別，上例中所聲明的一切都在該函數(shù)自身作用域中，與全局作用域相脫離。這意味著，無論未來在系統(tǒng)中發(fā)生什么，位于該函數(shù)中的任何內(nèi)容都會被隔離開來。命名空間(Namespacing)在最后一行中，你會發(fā)現(xiàn)我們要么把window.lab49賦給其自身，要么把空對象直接量(emptyobjectliteral)賦給它。盡管看起來有些奇怪，但是讓我們一起看下某個虛構(gòu)的系統(tǒng)，在那里我們擁有若干js文件，所有文件都用了上例中的函數(shù)包裝器(functionwrapper)。首個包含進(jìn)來的文件會評估OR(邏輯或)語句，并發(fā)現(xiàn)左側(cè)表達(dá)式為undefined(未定義)。由于

5、undefined是虛假值(falselyvalue),因此OR語句會繼續(xù)評估右側(cè)表達(dá)式，本例中是個空對象直接量。此OR語句實際上是個會返回評估結(jié)果的表達(dá)式，然后將結(jié)果賦給全局變量window.lab49?，F(xiàn)在，輪到下個文件來使用此模式了，它會獲得OR語句，并發(fā)現(xiàn)window.lab49當(dāng)前是對象實例真值(truthyvalue)。OR語句會短路并返回這個值，并將此值立即賦給其自身實際上啥也沒做。這導(dǎo)致的結(jié)果是，首個包含進(jìn)來的文件會創(chuàng)建我們的lab49命名空間(只是個JavaScript對象)，而且每個使用這種結(jié)構(gòu)的后續(xù)文件都只不過是重用這個現(xiàn)有實例。私有狀態(tài)(PrivateState)正如我

6、們剛才所說，由于位于函數(shù)內(nèi)部，在其內(nèi)部聲明的一切內(nèi)容都是處于該函數(shù)的范圍內(nèi)，而不是全局范圍。對于隔離我們的代碼這真太棒了，此外，它還有個影響是，沒有人能調(diào)用它。中看不中用。剛剛我們還談到，我們創(chuàng)建了window.lab49對象來有效管地理我們內(nèi)容的命名空間。而且這個lab49變量是全局可用的，因為它被附加到window對象上。要想把我們模塊中的內(nèi)容暴露給外部，你可以公開地說，我們要做的就是把一些值附加到全局變量上。正如我們在上例中對add函數(shù)所做的一樣?，F(xiàn)在，在我們的模塊外部可以通過lab49.add(2,2)來調(diào)用我們的add函數(shù)了。在此函數(shù)內(nèi)聲明我們的值的另一結(jié)果是，如果某個值不是通過將其

7、附加到我們的全局命名空間或者模塊外部的某物的方法來顯示公開的，那么外部代碼將無法碰到它。事實上，我們剛剛就創(chuàng)建了一些私有值。CommonJS模塊(CommonJSModules)CommonJS是一個主要由服務(wù)端JavaScript運行庫(server-sideJavaScriptruntimes)作者組成的小組，他們一直致力于暴露及訪問模塊的標(biāo)準(zhǔn)化工作(standardizeJavaScript運行庫作exposingandaccessingmodules)。值得注意的是，盡管他們提議的模塊系統(tǒng)不是來自于創(chuàng)建JavaScript標(biāo)準(zhǔn)同一小組的一個標(biāo)準(zhǔn)，因此它更多地成為者之間的非正式約定(in

8、formalconvention我通常支持CommonJS的想法，但要搞清楚的是：它并不是一份崇高而神圣的規(guī)范(就像ES5一樣)；它不過是某些人在郵件列表中所討論的想法。而且這些想法多數(shù)都沒有付諸實現(xiàn)。RyanDahl,node.js的創(chuàng)造者該模塊規(guī)范(Modulesspecification)的核心可謂開門見山。模塊(Modules)在它們自己的上下文中進(jìn)行評估，并且擁有全局變量exports以供模塊使用。變量exports只是個普通的JavaScript對象(plainoldJavaScriptobject),甚至你也可以往它上面附加內(nèi)容，與我們上面展示的命名空間對象類似。為了訪問某個模塊

9、，你要調(diào)用全局函數(shù)require,并指明你請求的包的標(biāo)示符(identifierforthepackage)。然后評估該模塊，并且無論返回什么都會附加到exports上。此模塊將會緩存起來，以便后來的require函數(shù)調(diào)用來使用。/calculator.jsexports.add=function(n1,n2);/app.jsvarcalculator=require(./calculator);calculator.add(2,2);如果你曾經(jīng)玩過Node.js,那么你會發(fā)現(xiàn)上面的代碼很熟悉。這種用Node來實現(xiàn)CommonJS模塊的方式是出奇地簡單，在node-inspector(一款No

10、de調(diào)試器)中查看某個模塊時將顯示其包裝在某個函數(shù)內(nèi)部的內(nèi)容，此函數(shù)正是傳遞給exports和require的值。非常類似于我們上面展示的手?jǐn)€模塊。有幾個node項目(Stitch和Browserify),它們將CommonJS模塊帶進(jìn)了瀏覽器。服務(wù)器端組件將這些彼此獨立的模塊js文件塞進(jìn)一個單獨的js文件中，并在那些代碼外面包上生成的模塊包裝器(generatedmodulewrapper)。CommonJS主要設(shè)計用于服務(wù)端JavaScript運行庫，而且由于有幾個屬性使得它們很難在瀏覽器中進(jìn)行客戶端代碼的組織。require必須立即返回一一當(dāng)你已經(jīng)擁有所有內(nèi)容時這會工作得非常好，但是當(dāng)使

11、用腳本加載器(scriptloader)異步下載腳本時就會有困難。每個文件一個模塊為了合并為CommonJS模塊，必須把它們包裹到一個函數(shù)中，然后再組織為某種式樣。如果沒有某些服務(wù)器組件，正如上面提到的那些，就會讓它們難以使用，并且在許多環(huán)境(ASP.NET,Java)下這些服務(wù)器組件尚不存在。異步模塊定義(AsynchronousModuleDefinition異步模塊定義(AsynchronousModuleDefinition,通常稱為AMD)已設(shè)計為適合于瀏覽器的模塊格式。它最初只是一個來自CommonJS小組的提議，但此后移到了GitHub上，而且現(xiàn)在伴有一個適用于模塊系統(tǒng)作者的測試

12、套件，以便驗證對于AMDAPI的遵從性(compliance)。AMD的核心是define函數(shù)。調(diào)用define函數(shù)最常見的方式是接受三個參數(shù)模塊名(也就是說不再與文件名綁定)、該模塊依賴的模塊標(biāo)識符數(shù)組、以及工廠函數(shù)，它將返回該模塊的定義。(還有其他的方式調(diào)用define函數(shù)一一詳細(xì)信息參閱AMDwiki)。define(calculator,adder,function(adder)returnadd:function(n1,n2)returnadder.add(n1,n2););由于此模塊的定義包在define函數(shù)的調(diào)用中，因此這就意味著，你可以愉快地在單個js文件內(nèi)擁有多個模塊。此外，

13、由于當(dāng)調(diào)用define模塊工廠函數(shù)時，模塊加載器擁有控制權(quán)，因此它可在閑暇之余解決(模塊之間的)依賴關(guān)系一一如果那些模塊必須首先異步下載，那就會很方便了。為了與原本的CommonJS模塊提議保持兼容已作出重大努力。當(dāng)在模塊工廠函數(shù)中使用require和exports時會有特殊處理，這意味著，那些傳統(tǒng)的CommonJS模塊可直接拿來用。看起來AMD正在成為頗受歡迎的組織客戶端JavaScript應(yīng)用程序的方式。無論是否通過如RequireJS或curl.js、或是像Dojo等最近已采用AMD的JavaScript應(yīng)用程序等模塊資源加載器來組織代碼。這是否意味著JavaScript很爛?(DoesthismeanJavaScriptsucks?)缺乏將代碼組織到模塊中的語言級別的結(jié)構(gòu)(languagelevelconstructs),這可能會讓來自于其他語言的開發(fā)者感覺很不爽。然而，正由于此缺陷才迫使JavaScript開發(fā)者想出他們自己的模塊構(gòu)造模式，我們已經(jīng)能夠隨著JavaScript應(yīng)用程序的發(fā)展進(jìn)行迭代和改進(jìn)。欲深入了解此主題請訪問Tagneto的博客。想象一下，即使這種功能類型(即Module)在10年前就已包括