The module pattern is a common JavaScript coding pattern. It’s generally well understood, but there are a number of advanced uses that have not gotten a lot of attention. In this article, I’ll review the basics and cover some truly remarkable advanced topics, including one which I think is original.

The Basics

We’ll start out with a simple overview of the module pattern, which has been well-known since Eric Miraglia (of YUI) first blogged about it three years ago. If you’re already familiar with the module pattern, feel free to skip ahead to “Advanced Patterns”.

Anonymous Closures

This is the fundamental construct that makes it all possible, and really is the single best feature of JavaScript. We’ll simply create an anonymous function, and execute it immediately. All of the code that runs inside the function lives in a closure, which provides privacy and state throughout the lifetime of our application.

(function () {
	// ... all vars and functions are in this scope only
	// still maintains access to all globals
}());

Notice the () around the anonymous function. This is required by the language, since statements that begin with the token function are always considered to be function declarations. Including () creates a function expression instead.

Global Import

JavaScript has a feature known as implied globals. Whenever a name is used, the interpreter walks the scope chain backwards looking for a var statement for that name. If none is found, that variable is assumed to be global. If it’s used in an assignment, the global is created if it doesn’t already exist. This means that using or creating global variables in an anonymous closure is easy. Unfortunately, this leads to hard-to-manage code, as it’s not obvious (to humans) which variables are global in a given file.

Luckily, our anonymous function provides an easy alternative. By passing globals as parameters to our anonymous function, we import them into our code, which is both clearer and faster than implied globals. Here’s an example:

(function ($, YAHOO) {
	// now have access to globals jQuery (as $) and YAHOO in this code
}(jQuery, YAHOO));

Module Export

Sometimes you don’t just want to use globals, but you want to declare them. We can easily do this by exporting them, using the anonymous function’s return value. Doing so will complete the basic module pattern, so here’s a complete example:

var MODULE = (function () {
	var my = {},
		privateVariable = 1;

	function privateMethod() {
		// ...
	}

	my.moduleProperty = 1;
	my.moduleMethod = function () {
		// ...
	};

	return my;
}());

Notice that we’ve declared a global module named MODULE, with two public properties: a method named MODULE.moduleMethod and a variable named MODULE.moduleProperty. In addition, it maintains private internal stateusing the closure of the anonymous function. Also, we can easily import needed globals, using the pattern we learned above.

Advanced Patterns

While the above is enough for many uses, we can take this pattern farther and create some very powerful, extensible constructs. Lets work through them one-by-one, continuing with our module named MODULE.

Augmentation

One limitation of the module pattern so far is that the entire module must be in one file. Anyone who has worked in a large code-base understands the value of splitting among multiple files. Luckily, we have a nice solution to augment modules. First, we import the module, then we add properties, then we export it. Here’s an example, augmenting our MODULE from above:

var MODULE = (function (my) {
	my.anotherMethod = function () {
		// added method...
	};

	return my;
}(MODULE));

We use the var keyword again for consistency, even though it’s not necessary. After this code has run, our module will have gained a new public method named MODULE.anotherMethod. This augmentation file will also maintain its own private internal state and imports.

Loose Augmentation

While our example above requires our initial module creation to be first, and the augmentation to happen second, that isn’t always necessary. One of the best things a JavaScript application can do for performance is to load scripts asynchronously. We can create flexible multi-part modules that can load themselves in any order with loose augmentation. Each file should have the following structure:

var MODULE = (function (my) {
	// add capabilities...

	return my;
}(MODULE || {}));

In this pattern, the var statement is always necessary. Note that the import will create the module if it does not already exist. This means you can use a tool like LABjs and load all of your module files in parallel, without needing to block.

Tight Augmentation

While loose augmentation is great, it does place some limitations on your module. Most importantly, you cannot override module properties safely. You also cannot use module properties from other files during initialization (but you can at run-time after intialization). Tight augmentation implies a set loading order, but allows overrides. Here is a simple example (augmenting our original MODULE):

var MODULE = (function (my) {
	var old_moduleMethod = my.moduleMethod;

	my.moduleMethod = function () {
		// method override, has access to old through old_moduleMethod...
	};

	return my;
}(MODULE));

Here we’ve overridden MODULE.moduleMethod, but maintain a reference to the original method, if needed.

Cloning and Inheritance

var MODULE_TWO = (function (old) {
	var my = {},
		key;

	for (key in old) {
		if (old.hasOwnProperty(key)) {
			my[key] = old[key];
		}
	}

	var super_moduleMethod = old.moduleMethod;
	my.moduleMethod = function () {
		// override method on the clone, access to super through super_moduleMethod
	};

	return my;
}(MODULE));

This pattern is perhaps the least flexible option. It does allow some neat compositions, but that comes at the expense of flexibility. As I’ve written it, properties which are objects or functions will not be duplicated, they will exist as one object with two references. Changing one will change the other. This could be fixed for objects with a recursive cloning process, but probably cannot be fixed for functions, except perhaps with eval. Nevertheless, I’ve included it for completeness.

Cross-File Private State

One severe limitation of splitting a module across multiple files is that each file maintains its own private state, and does not get access to the private state of the other files. This can be fixed. Here is an example of a loosely augmented module that will maintain private state across all augmentations:

var MODULE = (function (my) {
	var _private = my._private = my._private || {},
		_seal = my._seal = my._seal || function () {
			delete my._private;
			delete my._seal;
			delete my._unseal;
		},
		_unseal = my._unseal = my._unseal || function () {
			my._private = _private;
			my._seal = _seal;
			my._unseal = _unseal;
		};

	// permanent access to _private, _seal, and _unseal

	return my;
}(MODULE || {}));

Any file can set properties on their local variable _private, and it will be immediately available to the others. Once this module has loaded completely, the application should call MODULE._seal(), which will prevent external access to the internal _private. If this module were to be augmented again, further in the application’s lifetime, one of the internal methods, in any file, can call _unseal() before loading the new file, and call _seal() again after it has been executed. This pattern occurred to me today while I was at work, I have not seen this elsewhere. I think this is a very useful pattern, and would have been worth writing about all on its own.

Sub-modules

Our final advanced pattern is actually the simplest. There are many good cases for creating sub-modules. It is just like creating regular modules:

MODULE.sub = (function () {
	var my = {};
	// ...

	return my;
}());

While this may have been obvious, I thought it worth including. Sub-modules have all the advanced capabilities of normal modules, including augmentation and private state.

Conclusions

Most of the advanced patterns can be combined with each other to create more useful patterns. If I had to advocate a route to take in designing a complex application, I’d combine loose augmentationprivate state, and sub-modules.

I haven’t touched on performance here at all, but I’d like to put in one quick note: The module pattern is good for performance. It minifies really well, which makes downloading the code faster. Using loose augmentation allows easy non-blocking parallel downloads, which also speeds up download speeds. Initialization time is probably a bit slower than other methods, but worth the trade-off. Run-time performance should suffer no penalties so long as globals are imported correctly, and will probably gain speed in sub-modules by shortening the reference chain with local variables.

To close, here’s an example of a sub-module that loads itself dynamically to its parent (creating it if it does not exist). I’ve left out private state for brevity, but including it would be simple. This code pattern allows an entire complex heirarchical code-base to be loaded completely in parallel with itself, sub-modules and all.

var UTIL = (function (parent, $) {
	var my = parent.ajax = parent.ajax || {};

	my.get = function (url, params, callback) {
		// ok, so I'm cheating a bit :)
		return $.getJSON(url, params, callback);
	};

	// etc...

	return parent;
}(UTIL || {}, jQuery));

I hope this has been useful, and please leave a comment to share your thoughts. Now, go forth and write better, more modular JavaScript!

中文解釋:

模組模式是JavaScript一種常用的編碼模式。這是一般的理解,但也有一些高階應用沒有得到很多關注。在本文中,我將回顧基礎知識,瀏覽一些不錯的高階技巧,甚至我認為是原生基礎的。
 

基礎知識

首先我們開始簡單概述模型模式。三年前Eric Miraglia(YUI)的博文使模型模式眾所周知。如果你已經很熟悉模型模式,可以直接閱讀“高階模式”。

匿名閉包

這是一切成為可能的基礎,也是JavaScript最好的特性。我們將簡單的建立匿名函式,並立即執行。所有函式內部程式碼都在閉包(closure)內。它提供了整個應用生命週期的私有和狀態。

(function () {
	// ... all vars and functions are in this scope only
	// still maintains access to all globals
}());

注意匿名函式週圍的()。這是語言的要求。關鍵字function一般認為是函式宣告,包括()就是函式表示式。

 

引入全域性

JavaScript有個特性,稱為隱性全域性。使用變數名稱時,直譯器會從作用域向後尋找變數宣告。如果沒找到,變數會被假定入全域性(以後可以全域性呼叫)。如果會被分配使用,在還不存在時全域性建立它。這意味著在匿名函式裡使用全域性變數很簡單。不幸的是,這會導致程式碼難以管理,檔案中不容易區分(對人而言)哪個變數是全域性的。

幸好,匿名函式還有一個不錯的選擇。全域性變數作為引數傳遞給匿名函式。將它們引入我們的程式碼中,既更清晰,又比使用隱性全域性更快。下面是一個例子:

(function ($, YAHOO) {
	// 當前域有許可權訪問全域性jQuery($)和YAHOO
}(jQuery, YAHOO));
 
 翻譯得不錯哦!
 

模組出口

有時你不只想用全域性變數,但你需要先宣告他們(模組的全域性呼叫)。我們用匿名函式的返回值,很容易輸出他們。這樣做就完成了基本的模組模式。以下是一個完整例子:

var MODULE = (function () {
	var my = {},
		privateVariable = 1;
	
	function privateMethod() {
		// ...
	}
	
	my.moduleProperty = 1;
	my.moduleMethod = function () {
		// ...
	};
	
	return my;
}());

注意,我們宣告瞭一個全域性模組MODULE,有兩個公開屬性:方法MODULE.moduleMethod和屬性MODULE.moduleProperty。而且,匿名函式的閉包還維持了私有內部狀態。同時學會之上的內容,我們就很容易引入需要的全域性變數,和輸出到全域性變數。

 

高階模式

對許多使用者而言以上的還不足,我們可以採用以下的模式創造強大的,可擴充套件的結構。讓我們使用MODULE模組,一個一個繼續。

擴充

模組模式的一個限制是整個模組必須在一個檔案裡。任何人都瞭解長程式碼分割到不同檔案的必要。還好,我們有很好的辦法擴充模組。(在擴充檔案)首先我們引入模組(從全域性),給他新增屬性,再輸出他。下面是一個例子擴充模組:

var MODULE = (function (my) {
	my.anotherMethod = function () {
		// 此前的MODULE返回my物件作為全域性輸出,因此這個匿名函式的引數MODULE就是上面MODULE匿名函式裡的my
	};

	return my;
}(MODULE));

我們再次使用var關鍵字以保持一致性,雖然其實沒必要。程式碼執行後,模組獲得一個新公開方法MODULE.anotherMethod。擴充檔案沒有影響模組的私有內部狀態

 

鬆耦合擴充

上面的例子需要我們首先建立模組,然後擴充它,這並不總是必要的。提升JavaScript應用效能最好的操作就是非同步載入指令碼。因而我們可以建立靈活多部分的模組,可以將他們無順序載入,以鬆耦合擴充。每個檔案應有如下的結構:

var MODULE = (function (my) {
	// add capabilities...
	
	return my;
}(MODULE || {}));

這個模式裡,var語句是必須的,以標記引入時不存在會建立。這意味著你可以像LABjs一樣同時載入所有模組檔案而不被阻塞。

 
 

緊耦合擴充

雖然鬆耦合很不錯,但模組上也有些限制。最重要的,你不能安全的覆寫模組屬性(因為沒有載入順序)。初始化時也無法使用其他檔案定義的模組屬性(但你可以在初始化後執行)。緊耦合擴充意味著一組載入順序,但是允許覆寫。下面是一個例子(擴充最初定義的MODULE):

var MODULE = (function (my) {
	var old_moduleMethod = my.moduleMethod;
	
	my.moduleMethod = function () {
		// method override, has access to old through old_moduleMethod...
	};
	
	return my;
}(MODULE));

我們覆寫的MODULE.moduleMethod,但依舊保持著私有內部狀態

 

克隆和繼承

var MODULE_TWO = (function (old) {
	var my = {},
		key;
	
	for (key in old) {
		if (old.hasOwnProperty(key)) {
			my[key] = old[key];
		}
	}
	
	var super_moduleMethod = old.moduleMethod;
	my.moduleMethod = function () {
		// override method on the clone, access to super through super_moduleMethod
	};
	
	return my;
}(MODULE));

這種方式也許最不靈活。他可以實現巧妙的組合,但是犧牲了靈活性。正如我寫的,物件的屬性或方法不是拷貝,而是一個物件的兩個引用。修改一個會影響其他。這可能可以保持遞迴克隆物件的屬性固定,但無法固定方法,除了帶eval的方法。不過,我已經完整的包含了模組。(其實就是做了一次淺拷貝)。

 

跨檔案私有狀態

一個模組分割成幾個檔案有一個嚴重缺陷。每個檔案都有自身的私有狀態,且無權訪問別的檔案的私有狀態。這可以修復的。下面是一個鬆耦合擴充的例子,不同擴充檔案之間保持了私有狀態:

var MODULE = (function (my) {
	var _private = my._private = my._private || {},
		_seal = my._seal = my._seal || function () {
			delete my._private;
			delete my._seal;
			delete my._unseal;
		},//模組載入後,呼叫以移除對_private的訪問許可權
		_unseal = my._unseal = my._unseal || function () {
			my._private = _private;
			my._seal = _seal;
			my._unseal = _unseal;
		};//模組載入前,開啟對_private的訪問,以實現擴充部分對私有內容的操作
	
	// permanent access to _private, _seal, and _unseal
	
	return my;
}(MODULE || {}));

任何檔案都可以在本地的變數_private中設定屬性,他會對別的擴充立即生效(即初始化時所有擴充的私有狀態都儲存在_private變數,並被my._private輸出)。模組完全載入了,應用呼叫MODULE._seal()方法阻止對私有屬性的讀取(幹掉my._private輸出)。如果此後模組又需要擴充,帶有一個私有方法。載入擴充檔案前呼叫MODULE._unseal()方法(恢復my._private,外部恢復操作許可權)。載入後呼叫再seal()。 

子模組

最後的高階模式實際上最簡單。有很多好方法建立子模組。和建立父模組是一樣的:

MODULE.sub = (function () {
	var my = {};
	// 就是多一級名稱空間
	
	return my;
}());

雖然很簡單,但我還是提一下。子模組有所有正常模組的功能,包括擴充和私有狀態。

 
 
標籤: javascript