JavaScript: The Definitive Guide, Sixth Editio javaScript权威指南(第6版) pdf 文字版-文字版, javascript电子书, 和javascript 有关的电子书:

9.9.1 Objects As Namespaces

9.9.1 Objects As Namespaces

One way for a module to avoid the creation of global variables is to use an object as its namespace. Instead of defining global functions and variables, it stores the functions and values as properties of an object (which may be referenced by a global variable). Consider the Set class of Example 9-6 . It defines a single global constructor function Set. It defines various instance methods for the class, but it stores them as properties of Set.prototype so they are not globals. That example also defines a _v2s() utility function, but instead of making it a global function, it stores it as a property of Set.

Next, consider Example 9-16 . That example defined a number of abstract and concrete set classes. Each class had only a single global symbol, but the whole module (the single file of code) defined quite a few globals. From the standpoint of a clean global name-space, it would be better if this module of set classes defined a single global:

var sets = {};

This sets object is the namespace for the module, and we define each of the set classes as a property of this object:

sets.SingletonSet = sets.AbstractEnumerableSet.extend(...);

When we want to use a class defined like this, we simply include the namespace when we refer to the constructor:

var s = new sets.SingletonSet(1);

The author of a module cannot know what other modules their module will be used with and must guard against name collisions by using namespaces like this. The programmer who uses the module, however, knows what modules are in use and what names are defined. This programmer doesn’t have to keep using the namespaces rigidly, and can import frequently used values into the global namespace. A programmer who was going to make frequent use of the Set class from the sets namespace might import the class like this:

var Set = sets.Set; // Import Set to the global namespace var s = new Set(1,2,3); // Now we can use it without the sets prefix.

Sometimes module authors use more deeply nested namespaces. If the sets module was part of a larger group of collections modules, it might use collections.sets as a name-space, and the module would begin with code like this:

var collections; // Declare (or re-declare) the single global variable

if (!collections) // If it doesn't already exist

collections = {}; // Create a toplevel namespace object

collections.sets = {} // And create the sets namespace within that.

// Now start defining our set classes inside collections.sets

collections.sets.AbstractSet = function() { ... }

Sometimes the top-level namespace is used to identify the person or organization that created the modules and prevent name collisions between namespace names. The Google Closure library, for example, defines its Set class in the namespace goog.structs. Individuals can reverse the components of an Internet domain name to create a globally unique namespace prefix that is unlikely to be in use by any other module authors. Since my website is at, I could publish my sets module in the name-space com.davidflanagan.collections.sets.

With namespaces this long, importing values becomes important for any user of your module. Rather than importing individual classes, however, a programmer might import the entire module to the global namespace:

var sets = com.davidflanagan.collections.sets;

By convention, the filename of a module should match its namespace. The sets module should be stored in a file named sets.js. If that module uses the namespace collections.sets, then this file should be stored in a directory named collections/ (this

9.9 Modules | 247

directory might also include a file named maps.js). And a module that used the name-space com.davidflanagan.collections.sets would be in com/davidflanagan/collections/ sets.js.

友情链接It题库(| 版权归yishouce.com所有| 友链等可联系|粤ICP备16001685号-1