全局变量是魔鬼，这句话在JavaScript存在的地方应该就是成立的，当然Firefox扩展也不例外，如果大家把多于一个的对象置于全局命名空间下，和其他扩展的冲突是很容易发生的，而且发现这种冲突引起的错误是很困难的，因为每个人的扩展列表都不一样啊。避免全局名字污染已经成了一个基本原则，本文从这点引申，介绍了一个应用在Firebug中的扩展架构模式，非常值得推荐。

【原文】Firefox Extensions: Global Namespace Pollution
【作者】Jan Odvarko
【译文】http://cuimingda.com/2009/01/
【译者】明达

以下是对原文的翻译：

最近有几个开发者向我咨询如何设计Firefox扩展的架构，第一个显现在我脑海中的答案就是要合理定义那些在ChromeWindow作用域下的全局变量。

不合理的定义全局变量，可以轻易的引发不同扩展之间的冲突，而这些完全是应该避免的（这也是AMO审阅的步骤之一），因为冲突所引发的问题是很难被发现的。就目前的开发环境来说，全局变量就是魔鬼，尤其是采用OOP开发模式的时候。

我不想重复介绍如何从头开始开发一个Firefox扩展，对于这方面已经有很多非常详细的文章。本文的重点放在如何设计一个更加易于维护的Firefox扩展架构。

如果你对前面的介绍感兴趣，那就接着看吧。。。

命名空间架构

扩展之间发生冲突的重要原因就是因为定义了不合理的全局变量。我认为对每个扩展来说，只有一个全局变量已经很足够了（可以根据扩展的信息来定义这个唯一的全局变量的名字，比如可以是扩展的名字、域名、地址等），不仅可以满足我们的开发，而且可以避免那些令人讨厌的冲突。

Firebug使用的命名空间架构，基本建立在著名的Module Pattern基础上（这种模式最早由Douglas Crockfod定义）下的。这种模式简单而清晰，但其实我在很长时间里都不是很明确这种模式究竟是如何工作的（I hadn’t understand how it actually works for a long time）。我相信每个开发者都可以充分利用这个方法。

基本的思路是将每个JavaScript脚本文件放进自己的作用域，这是通过一个函数来实现的，没有定义任何全局变量，比如下面这段代码：

function() {
  // TODO: 脚本文件中的全部代码
}

我管这个函数就叫做命名空间。摆在眼前的第一个问题是，如何确定这个函数的内容会在正确的时间被调用。第二个问题是，如何在多个脚本文件中共享对象（这个会在后面的章节解答）。 Firebug通过将所有的命名空间进行注册，并在Firefox chrome UI加载的时候调用来解决第一个问题，也就是下面这段代码：

myExtension.ns(function()
{
  // TODO: 脚本文件中的全部代码
});

命名空间（就是原来定义的那个函数）为当作myExtension.ns函数的一个参数，而myExtension对象是这个扩展中定义的唯一全局变量。这个对象代表着整个扩展。不用担心这个名字太长，我们可以为他建立个快捷方式（在实际开发中，这个名字可能会类似 comSoftwareIsHardMyExtension这个样子）。

ns函数比较简单，就是把所有的方法都添加到一个数组中。

var namespaces = [];
this.ns = function(fn)
{
  var ns = {};
  namespaces.push(fn, ns);
  return ns;
};

执行已注册命名空间的函数，不可以命名为apply，别的什么名字都可以。

this.initialize = function() {
  for (var i = 0; i < namespaces.length; i += 2) {
      var fn = namespaces[i];
      var ns = namespaces[i + 1];
      fn.apply(ns);
  }};

现在，然我们把前面的代码连起来，看看全局扩展对象是如何定义和初始化的。