原文:https://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript
模块
模块是任何健壮的应用程序架构所必备的部分,通常有助于保持项目代码单元清晰的分离和组织。
在 JavaScript 中,有几种方式来实现模块。它们是:
- 模块模式
- 对象字面量表示法
- AMD 模块
- CommonJS 模块
- ECMAScript 标准模块
我们随后将在本书的 现代模块化 JavaScript 设计模式 章节中来探讨后三种方案。
模块模式 是部分基于对象字面量,所以我们有必要先重新回顾一下相关知识。
对象字面量
在对象字面量表示法中,对象被描述为一系列被花括号({})包裹,逗号分隔的键值对组成。对象中的键可以是任何字符或者符号,并且会跟随着一个冒号。最后一组键值对后不应该再有逗号,因为它可能会引起程序报错。
var myObjectLiteral = {variableKey: variableValue,functionKey: function() {// ...}};
对象字面量不需要用 new 操作符来实例化,但是不应该在语句的开头使用,因为 { 可能会被解释成块的开始。在对象外,可以使用以下方式来为其添加成员:myMofule.property = "someValue"。
下面我们将看到用对象字面量来定义模块的更复杂的示例:
var myModule = {myProperty: "someValue",// 对象字面量可以包含属性和方法// 例如我们可以定义一个嵌套对象来存储更多的模块配置myConfig: {useCacing: true,language: "em"},// 一个简单的方法saySomething: function() {console.log("Where in the world is Pual Irish today?");},// 根据当前模块配置信息输出值reportMyConfig: function() {console.log("Caching is: " + ( this.myConfig.useCaching ? "enable" : "disabled") );},// 覆盖当前的配置updateMyConfig: function(newConfig) {if (typeof newConfig === "object") {this.myConfig = newConfig;console.log(this.myConfig.language);}},};// 输出:Where in the world is Paul Irish today?myModule.saySomething();// 输出: Caching is: enabledmyModule.reportMyConfig();// 输出: frmyModule.updateMyConfig({language: "fr",useCaching: false});// 输出: Caching is disabledmyModule.reportMyConfig();
使用对象字面量有助于封装和组织你的代码,如果你希望进一步了解对象字面量,你可以阅读 Rebecca Muerphey 先前关于这个话题的深度讨论。
也就是说,如果我们选择这种技术,我们可能同样会对 模块模式 感兴趣。它也是使用对象字面量,但是只是作为一个闭包函数的返回值来使用。
模块模式
模块模式最初被定义为在传统软件工程中为类提供私有和公共封装的一种方式。
在 JavaScript 中,模块模式被用来进一步模拟类的概念,在这种方式中,我们能够在一个对象中包含公公共/私有的方法和变量,从而将特定部分从全局作用域中隔离出来。它能带来的好处就是减少我们的函数名与页面内其他脚本中的函数名的冲突的可能性。
私有的
模块模式使用闭包封装了“隐私的”、状态和组织。它提供了一种方式来封装公共和私有的方法和变量,保护片段不泄漏到全局作用域内,不与另外的开发者的接口发生意外的冲突。使用这种模式,只有公共的 API 会被返回,将闭包中其他内容保持为私有。
这为我们提供了一种干净的解决方案来保护执行繁重任务的逻辑,同时只暴露我们希望程序其他部分可以使用的接口。这个模式使用的是一个会返回一个对象的立即执行的函数(IIFE,参考 命名空间 模式来了解更多)。
应该注意的是,在 JavaScript 中并没有真正意义上的“私有”,因为与一些传统语言不同,它没有访问修饰符。理论上来说,变量不能被声明为公共或者私有,所以我们使用函数作用域来模拟这个概念。在模块模式中,由于闭包的作用,定义的变量和方法都只能在模块内部访问。定义在返回对象中的变量和方法却是任何人都可以访问。
历史
从历史的角度来看,模块模式最早由 Richard Cornford 等人在2003年最早开发出来。随后通过 Douglas Crockford 的讲座得到推广。另外一个细节就是,如果你曾经使用过 Yahoo 的 YUI 库,会发现它的一些特征可能看起来很相似,这是因为模块模式在创建组件时对 YUI 有很大影响。
示例
我们先通过创建一个独立的模块来学习模块模式的实现。
var testModule = (var counter = 0;return {incrementCounter: function(){return counter++;},resetCounter: function() {console.log("counter value prior to reset: " + counter);counter = 0;}};)();// 用法:// 增加我们的 countertestModule.incrementCounter();// 检查我们的 counter 值,然后重置// 输出:counter value prior to reset: 1testModule.resetCounter();
本例中,其他部分的代码是无法直接读取 incrementCounter() 或者 resetCounter() 的值。counter 变量实际上完全从全局作用域隔离开的,它就相当于是一个私有变量 ,它只存在模块的闭包内,所以只有我们的两个函数能访问到它。我们的方法是实际被限定到命名空间了,所以在测试代码部分,我们需要在方法调用前再加上模块名作为前缀(例如:”testModule”)。
使用模块模式时,我们会发现定义一个简单的模板来开始使用它是很有用的。下面是一个包含了命名空间、公/私有变量的示例:
var myNamespace = (function() {var myPrivateVar, myPrivateMethod;// 一个私有的counter变量myPrivateVar = 0;// 一个私有的方法来记录入参myPrivateMethod = function(foo) {console.log(foo);};return {// 一个公有的变量myPublicVar: "foo",// 一个公有的方法来访问私有部分myPublicMethod: function(bar) {// 增加我们私有的 countermyPrivateVar++;// 调用我们私有的方法myPrivateMethod(bar);}};})();
来看另一个例子,下面将会用这个模式来实现一个购物车。模块本身被完全独立在一个名为 basketModule 的全局变量中。模块中的数组 basket 是私有的,所以我们应用其他部分是无法直接读取到它。它只存在在模块的闭包内,只能通过能访问这个闭包的方法访问它(即 addItem() 、getItemCount() 等)。
var basketModule = (function() {// 私有的var basket = [];function doSomethingPrivate() {// ...}function doSomethingElsePrivate() {// ...}// 返回一个对象暴露出去return {// 添加到购物车addItem: function(values) {basket.push(values);},// 返回购车物品数量getItemCount: function() {return basket.length;},// 公有方法映射到私有方法doSomething: doSomethingPrivate,// 返回购物车中的总额getTotal: function() {var q = this.getItemCount(),p = 0;while(q--) {p += basket[q].price;}return p;}};})();
你可能注意到了我们在模块内部返回了一个对象。它自动的分配到 basketModule 变量,这样这样来使用它:
// basketModule 返回一个保护公共 API 的对象供我们使用basketModule.addItem({ item: "bread", price: 0.5 });basketModule.addItem({ item: "butter", price: 0.3 });// 输出:2console.log(basketModule.getItemCount());// 输出:0.8console.log(basketModule.getTotal());// 然而,下面的代码不会生效// 输出:undefined// 这是因为 basket 没有通过我们的公共 API 暴露出来console.log(basketModule.basket);// 这也行不通,因为它只存在 basketModule 闭包范围内,不在返回的公共对象上console.log(basket);
上面这些方法有效的被限定在 basketModule 命名空间内。
注意 basket 模块的作用域函数是如何包裹我们所有的函数,我们随后调用它并立即存储它的返回值。这种方式有一些好处:
- 自由的拥有私有方法和私有成员,它们只在我们模块内部使用。因为它们没有暴露给页面其他部分(只有我们导出的公共API才暴露了出去),它们可以认为是真正的私有的。
- 假设函数正常的声明并命名,它能让我们在通过调用堆栈查找出哪个函数抛出异常更加方便。
- 正如 T.J Crowder 先前指出的,它还能让我们根据环境返回不同的函数。在过去,我看到过开发者使用这种方式来检测 UA,以便为 IE 浏览器提供一个特殊的代码路径,但是我们现在可以更容易的使用特性检测来实现类似的目标。
模块模式的演变
Import mixins
这个模式的演变示范了全局变量(如 jQuery、UnderScore)如何通过参数传递给我们模块的匿名函数。这能有效的使我们能够导入它们,并在内部按照我们的意愿来为它重命名。
// 全局模块var myModule = (function ( jQ, _ ) {function privateMethod1(){jQ(".container").html("test");}function privateMethod2(){console.log( _.min([10, 5, 100, 2, 1000]) );}return{publicMethod: function(){privateMethod1();}};// 导入jQuery和underscore})( jQuery, _ );myModule.publicMethod();
Exports
这个演变让我们能够在不使用它们的情况下声明全局变量,并且可以类似的支持上一个例子那样的全局变量导入的概念。
// 全局模块var myModule = (function () {// 模块对象var module = {},privateVariable = "Hello World";function privateMethod() {// ...}module.publicProperty = "Foobar";module.publicMethod = function () {console.log( privateVariable );};return module;})();
工具和特定框架的模块声明
Dojo
Dojo 提供了一个名为 dojo.setObject() 的便捷方法来配合对象使用。它的第一个参数接收以 . 为分割符的字符,如 myObj.parent.child ,它会定义在 myObj 中定义一个含有 child 属性的属性 parent 。使用 setObject()允许我们设置子属性的值,并且会在中间节点不存在的情况下自动声明其值为对象。
例如,如果我们想声明 basket.core 作为 store 命名空间下的一个对象,可以通过下面这种传统的方式实现:
var store = window.store || {};if ( !store["basket"] ) {store.basket = {};}if ( !store.basket["core"] ) {store.basket.core = {};}store.basket.core = {// ...剩余逻辑};
或者像下面一样使用 Dojo 1.7 及以上(适配 AMD 版本):
require(["dojo/_base/customStore"], function( store ){// 使用 dojo.setObject()store.setObject( "basket.core", (function() {var basket = [];function privateMethod() {console.log(basket);}return {publicMethod: function(){privateMethod();}};})());});
想了解更多关于 dojo.setObject() 的信息,可以查看官方文档。
ExtJS
对于那些使用 Sencha 的 ExtJS 的开发者,下面是一个演示如何在框架中正确的使用模块模式的示例。
这里,我们看到一个关于如何定义一个命名空间的例子,它可以声明一个包含公有/私有 API 的模块。除了一些语法上的差异,它和使用普通的 JavaScript 声明模块模式类似。
// 创建命名空间Ext.namespace("myNameSpace");// 创建应用程序myNameSpace.app = function () {// 不要在这里访问DOM节点,元素还不存在// 私有变量var btn1,privVar1 = 11;// 私有方法var btn1Handler = function ( button, event ) {console.log( "privVar1=" + privVar1 );console.log( "this.btn1Text=" + this.btn1Text );};// 公有空间return {//公共属性, 例如: 要翻译的字符btn1Text: "Button 1",// 公有的方法init: function () {if ( Ext.Ext2 ) {btn1 = new Ext.Button({renderTo: "btn1-ct",text: this.btn1Text,handler: btn1Handler});} else {btn1 = new Ext.Button( "btn1-ct", {text: this.btn1Text,handler: btn1Handler});}}};}();
YUI
同样的,在使用 YUI3 来创建应用时,我们也可以使用模块模式。下面的例子很大程度是基于 Eric Miraglia 实现的最初版的 YUI 模块模式,但同样,它也普通的 JavaScript 版本没有太大的区别。
Y.namespace( "store.basket" ) ;Y.store.basket = (function () {var myPrivateVar, myPrivateMethod;// 私有变量:myPrivateVar = "I can be accessed only within Y.store.basket.";// 私有方法:myPrivateMethod = function () {Y.log( "I can be accessed only from within YAHOO.store.basket" );}return {myPublicProperty: "I'm a public property.",myPublicMethod: function () {Y.log( "I'm a public method." );// 在 basket 中,我们可以访问私有变量和方法:Y.log( myPrivateVar );Y.log( myPrivateMethod() );// myPublicMethod 的 native scope 是 store// 所以我们可以通过 this 来获取公共成员:Y.log( this.myPublicProperty );}};})();
jQuery
有很多种方式可以将不依赖于插件的 jQuery 代码包装在模块模式内。Ben Cherry 之前提出一种实现方式, 如果模块之间存在很多共性,则用 包装函数 来定义模块。
在下面的例子中,定义了一个library 函数,它声明了一个新的 library ,并在创建新的 libraries (即: modules)时自动的将 init 函数到 document.ready 上。library 函数就是一个包装函数。
function library( module ) {// $(function() {...}) 等效于 $(document).ready(function() { ... });$( function() {if ( module.init ) {module.init();}});return module;}var myLibrary = library(function () {return {init: function () {// 模块声明}};}());
优点
我们已经明白了为什么构造器模式是有用的,但是为什么模块模式是一个好的选择?对初学者来说,对于有面向对象经验的开发者来说,它比真正的封装思想要更清晰,至少从 JavaScript 角度来看。
其次,它支持私有数据 — 因此,在模块模式内部,我们公共部分的代码能访问私有部分,但是外部的代码是无法访问类的私有部分(不准笑!感谢 David Engfer 提供的这个笑话)。
缺点
模块模式的缺点是因为我们访问公有和私有成员方式不同,当我们要改变一个成员的可见性时,我们需要修改所有使用到它的地方。
我们也不能在模块创建后再添加到对象上的方法中访问私有成员。也就是说,如果使用得当,很多情况下模块模式都是有用的,它肯定是能够帮助优化我们代码的结构。
其他的缺点有:不能为私有成员创建自动化单元测试,而且在需要热修复代码时,难度会增加。根本不可能以补丁的方式修复私有部分的问题。相反,必须覆盖与有 bug 的私有部分有交互的所有公共方法。 开发者也不能轻易的拓展私有部分,所以有必要记住私有并不像他们最初看起来那样灵活。
想了解更多关于模块模式的内容,可以阅读 Ben Cherry 的这边很有深度的 文章。
