JavaScript 中的命名空间技术，推荐吗？高性能？需要注意的问题？答案

【问题标题】：Namespacing technique in JavaScript, recommended? performant? issues to be aware of?JavaScript 中的命名空间技术，推荐吗？高性能？需要注意的问题？
【发布时间】：2011-01-07 08:07:02
【问题描述】：

在project 我正在研究我的代码结构如下

MyLib = {
    AField:0,

    ASubNamespace:{
        AnotherField:"value",

        AClass:function(param) {
            this.classField = param;

            this.classFunction = function(){
                // stuff
            }
        }
    },

    AnotherClass:function(param) {
        this.classField = param;

        this.classFunction = function(){
            // stuff
        }
    }
}

等等类似的事情来做这样的事情：

var anInstance = new MyLib.ASubNamespace.AClass("A parameter.");

这是实现命名空间的正确方法吗？是否有性能影响，如果有，影响有多大？当我嵌套更深时，性能下降会叠加吗？使用此结构时我还应该注意其他问题吗？

我关心每一点性能，因为它是一个实时图形库，所以我非常重视任何开销。

【问题讨论】：

Essential JS Design Patterns Book 包含关于命名空间模式的章节。

标签： javascript namespaces structure

【解决方案1】：

我建议命名空间是编写可维护 JavaScript 的关键部分 - 特别是如果您与开发人员团队合作。

如果您在生产过程中compress/minimize your code，与命名空间相关的性能问题应该是最小的。

这里是an SO discussion 使用命名空间的替代方法。

【讨论】：

【解决方案2】：

当您将代码构建为一个巨大的对象属性层次结构时，您有时会遇到MyNamespaceObj.prop1 对MyNamespaceObj.prop2 不可用的问题。还有一个事实是，您经常会在整个代码中大量输入完全限定名称。

我开始发现我更喜欢做这样的事情：

MyNamespaceObj = (function () {

    // lots of code/definitions that have local scope
    var internallyDefinedItem1 = function (n) { /* ... */ }
    var internallyDefinedItem2 = {
        foo: internallyDefinedItem1(532),
        bar: totallyPrivateNeverExportedFunction(17)
    }
    var totallyPrivateNeverExportedVar = 'blahblahblah';
    function totallyPrivateNeverExportedFunction (x) {
       /* ... */
    }

    return {
        exportedItem1: internallyDefinedItem1,
        exportedItem2: internallyDefinedItem2,
        ...
    }
})();

【讨论】：

我在处理最初需要这个问题的项目时发现，让任何东西完全私有可能对调试非常不利，因为在运行时获取这些值很痛苦。
确实如此。我主要是通过编写函数来解决它，这些函数在运行时在调试时将值记录到控制台（并将它们剥离），但是在一些调试器中很难设置一个表达式的监视，这绝对是令人讨厌的局部范围有限。不过，我认为这主要是工具的弱点，而不是技术的弱点。希望随着时间的推移得到解决。

【解决方案3】：

为 JavaScript 命名空间对于避免潜在的冲突和覆盖至关重要。当您的 JS 将登陆外部 JS 也可以驻留的外部环境时，尤其如此。

话虽如此，命名空间会对性能造成影响，仅仅是因为解释器现在必须遵循更长的链来访问所需的函数/属性。

例如，类似

  var myProperty;

访问速度比：

 myNameSpace.module1.myProperty;

我认为速度上的差异不大，除非您非常深入地命名空间并且避免潜在冲突的优势是命名空间的一大优势。

不过，记住这个问题总是好的。

【讨论】：