# 現代模塊化的Javascript設計模式 ## 對應用程序進行解耦的重要新 在具有可擴展性的Javascript的世界里，當我們說應用程序是模塊化的時候，我們的意思常常是它包含著一些高度解耦的各自獨立的存儲在模塊中的功能塊。松耦合便于通過移除依賴從而在可能的時候對應用進行維護。當這樣的便利性得到了有效實現的時候，就可以相當容易的看到系統的一個部分對其它部分可能產生的影響如何發生改變。 然而不像一些更加普遍的傳統的編程語言，JavaScript（ECMA-262）的當前版本并沒有使用一種干凈，結構化的方式為開發者提供導入此模塊的方法。它是直到近幾年對于更加結構化的Javascript應用程序的需求變得更加明顯，才作為規范需要著重考慮的問題之一。 反過來，現在的開發者只剩下回到帶有變異性質的模塊或者對象語法模式，這我們已經在本書的前面部分涵蓋到了。許多這些用于模塊化的腳本使用被描述成為全局對象的命名空間在DOM中串在一起，仍然有可能在我們的架構中產生命名沖突。缺少一些手工的嘗試或者第三方插件的幫助，這也不是一種控制依賴管理的干凈的方法。 雖然對于這些問題的本地解決方案將會到達ES Harmony(很有可能成為Javascript的下一個版本)，好消息是編寫模塊化的Javascript從來沒有變得更加簡單，而我們今天開始就可以開始這樣做了。 在本節中，我們將看一看編寫模塊化Javascript的三種形式：**AMD**，?**CommonJS**和建議的Javascript的下一個版本，**Harmony** ## 關于腳本加載器的一個需要注意的要點 在沒有談及房間里的大象——腳本加載器之前，要討論AMD和CommonJS的模塊是很困難的。在寫這本書的時候，腳本加載意味著一個目標，那個目標就是可以在今天的應用程序中使用的模塊化的Javascript——為此，使用與此兼容的腳本加載器，很不幸的說是必需的。為了能盡可能的獲取這一節的信息，我建議先對流行的腳本加載工具如何工作有一個基本的理解，以便在本文中對于模塊化形式的解釋有意思起來。 在AMD和CommonJS形式中有大量用于處理模塊加載的加載器，而我個人的選擇是RequireJS和curl.js。對于這些工具的完整教程超出了本書的范疇，但是我建議去讀John Hann的關于curl.js的文章，和James Burke的RequireJS API文檔，以獲取更多信息。 對于生產環境而言，使用優化工具（像RequireJS優化器）的來連結腳本，被提倡在這樣的模塊上工作時用于部署。有趣的是，有Almond AMD墊底，RequireJS并不需要卷入被部署的站點中，而人們可能會考慮的腳本加載器能夠簡單的在開發工作的外圍進行切換。 那就是說，James Burke將可能聲稱可以在頁面加載直到有用武之地后才動態加載腳本，并且RequireJS也能支持這一特性。將這些要點銘記于心了，那就讓我們開始吧。?