Question

在我正在研究的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.");

这是实现命名空间的正确方法吗？是否有性能命中，如果有，有多激烈？当我嵌套更深时，性能降级是否堆叠？使用这种结构时，我应该注意其他任何问题吗？

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

Answer 1

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

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

以下是an SO discussion使用命名空间的其他方法。

Answer 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,
        ...
    }
})();

Answer 3

命名空间JavaScript对于避免潜在的冲突和覆盖至关重要。当你的JS出现在外部JS也可以驻留的外国环境中时，这一点尤其正确。

话虽如此，由于命名空间而导致性能下降，仅仅是因为解释器现在必须遵循更长的链来访问所需的函数/属性。

例如，像

  var myProperty;

与以下相比，访问

的速度要快一些。

 myNameSpace.module1.myProperty;

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

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

推荐使用JavaScript中的命名空间技术？高性能？需要注意的问题？

3 个答案: