最新的模塊化 JavaScript 設(shè)計(jì)模式

現(xiàn)代模塊化的Javascript設(shè)計(jì)模式

對(duì)應(yīng)用程序進(jìn)行解耦的重要新

在具有可擴(kuò)展性的Javascript的世界里，當(dāng)我們說應(yīng)用程序是模塊化的時(shí)候，我們的意思常常是它包含著一些高度解耦的各自獨(dú)立的存儲(chǔ)在模塊中的功能塊。松耦合便于通過移除依賴從而在可能的時(shí)候?qū)?yīng)用進(jìn)行維護(hù)。當(dāng)這樣的便利性得到了有效實(shí)現(xiàn)的時(shí)候，就可以相當(dāng)容易的看到系統(tǒng)的一個(gè)部分對(duì)其它部分可能產(chǎn)生的影響如何發(fā)生改變。

然而不像一些更加普遍的傳統(tǒng)的編程語言，JavaScript（ECMA-262）的當(dāng)前版本并沒有使用一種干凈，結(jié)構(gòu)化的方式為開發(fā)者提供導(dǎo)入此模塊的方法。它是直到近幾年對(duì)于更加結(jié)構(gòu)化的Javascript應(yīng)用程序的需求變得更加明顯，才作為規(guī)范需要著重考慮的問題之一。

反過來，現(xiàn)在的開發(fā)者只剩下回到帶有變異性質(zhì)的模塊或者對(duì)象語法模式，這我們已經(jīng)在本書的前面部分涵蓋到了。許多這些用于模塊化的腳本使用被描述成為全局對(duì)象的命名空間在DOM中串在一起，仍然有可能在我們的架構(gòu)中產(chǎn)生命名沖突。缺少一些手工的嘗試或者第三方插件的幫助，這也不是一種控制依賴管理的干凈的方法。

雖然對(duì)于這些問題的本地解決方案將會(huì)到達(dá)ES Harmony(很有可能成為Javascript的下一個(gè)版本)，好消息是編寫模塊化的Javascript從來沒有變得更加簡(jiǎn)單，而我們今天開始就可以開始這樣做了。

在本節(jié)中，我們將看一看編寫模塊化Javascript的三種形式：AMD，?CommonJS和建議的Javascript的下一個(gè)版本，Harmony

關(guān)于腳本加載器的一個(gè)需要注意的要點(diǎn)

在沒有談及房間里的大象——腳本加載器之前，要討論AMD和CommonJS的模塊是很困難的。在寫這本書的時(shí)候，腳本加載意味著一個(gè)目標(biāo)，那個(gè)目標(biāo)就是可以在今天的應(yīng)用程序中使用的模塊化的Javascript——為此，使用與此兼容的腳本加載器，很不幸的說是必需的。為了能盡可能的獲取這一節(jié)的信息，我建議先對(duì)流行的腳本加載工具如何工作有一個(gè)基本的理解，以便在本文中對(duì)于模塊化形式的解釋有意思起來。

在AMD和CommonJS形式中有大量用于處理模塊加載的加載器，而我個(gè)人的選擇是RequireJS和curl.js。對(duì)于這些工具的完整教程超出了本書的范疇，但是我建議去讀John Hann的關(guān)于curl.js的文章，和James Burke的RequireJS API文檔，以獲取更多信息。

對(duì)于生產(chǎn)環(huán)境而言，使用優(yōu)化工具（像RequireJS優(yōu)化器）的來連結(jié)腳本，被提倡在這樣的模塊上工作時(shí)用于部署。有趣的是，有Almond AMD墊底，RequireJS并不需要卷入被部署的站點(diǎn)中，而人們可能會(huì)考慮的腳本加載器能夠簡(jiǎn)單的在開發(fā)工作的外圍進(jìn)行切換。

那就是說，James Burke將可能聲稱可以在頁面加載直到有用武之地后才動(dòng)態(tài)加載腳本，并且RequireJS也能支持這一特性。將這些要點(diǎn)銘記于心了，那就讓我們開始吧。?