12

在对该主题进行了一些研究之后，我一直在尝试使用模式来组织我的 jQuery 代码（例如，Rebecca Murphy 在 jQuery Conference 上对此进行了演示）。

昨天我检查了（揭示）模块模式。结果看起来有点像我认为的YUI语法：

//global namespace MyNameSpace
if(typeof MNS=="undefined"||!MNS){var MNS={};}

//obfuscate module, just serving as a very simple example
MNS.obfuscate = function(){
    //function to create an email address from obfuscated '@'
    var email = function(){
        $('span.email').each(function(){
            var emailAddress = $(this).html().replace(' [ @ ] ','@');
            $(this).html('<a href="mailto:' + emailAddress + '">' + emailAddress + '</a>');

        });
    };    
    return {
        email: email
    };    
}();

//using the module when the dom's ready
jQuery(document).ready(function($){
    MNS.obfuscate.email();
});

最后我有几个模块。一些自然包含“私有成员”，在这种情况下，这意味着变量和/或函数仅对该模块中的其他函数重要，因此不会出现在 return 语句中。

我认为将我的代码的连接部分（例如与搜索有关的所有内容）组合在一个模块中是有意义的，从而给出了整个事物的结构。

但在写完这篇文章后，我读了John (Resig) 的一篇文章，他还写了一篇关于模块模式性能的文章：

“用一堆原型属性实例化一个函数非常、非常、快。它完全颠覆了模块模式，以及类似的模式。因此，如果你有一个你想要的经常访问的函数（返回一个对象）要与之交互的人，那么将对象属性放在原型链中并实例化它对您有利。这里是，在代码中：

// Very fast
function User(){}
    User.prototype = { /* Lots of properties ... */ };

// Very slow
function User(){
    return { /* Lots of properties */ };
}

（John 提到他并不反对“本身”的模块模式——只是为了让你知道 :)

然后我不确定我的代码是否朝着正确的方向发展。问题是：我真的不需要任何私有成员，我也认为我暂时不需要继承。我现在想要的只是一个可读/可维护的模式。我想这在一定程度上归结为个人偏好，但我不想最终得到具有（相当严重）性能问题的可读代码。

我不是 JavaScript 专家，因此在性能测试方面更不是专家。所以首先，我真的不知道约翰提到的事情（“你希望人们与之交互的频繁访问的函数（返回一个对象）”，许多属性等）在多大程度上适用于我的代码。我的代码与之交互的文档并不大，只有 100 或 1000 多个元素。所以也许这根本不是问题。

但我想到的一件事是，不仅仅是拥有

$('span.email').each(function(){
    var emailAddress = $(this).html().replace(' [ @ ] ','@');
    $(this).html('<a href="mailto:' + emailAddress + '">' + emailAddress + '</a>');
});

（在 domready 函数内部），由于使用了模块模式，我创建了两个“额外”函数，混淆和电子邮件。创建附加功能需要一些时间。问题是：在我的情况下它可以衡量吗？

我不确定在上面的示例中是否创建了闭包（在 jQuery 论坛上的一篇有趣的帖子中，我读到以下内容：“关于内部函数是否在不引用任何内容时创建闭包存在哲学争论外部函数的变量对象...”），但我的真实代码中确实有闭包。即使我不认为我在那里有任何循环引用，我也不知道这会在多大程度上导致高（呃）内存消耗/垃圾收集问题。

我真的很想听听您对此的意见，并且可能会看到一些您的代码示例。此外，您更喜欢使用哪些工具来获取有关执行时间、内存和 CPU 使用率的信息？

4

2 回答 2

7

我也觉得暂时不需要继承

的确。这并不真正适用于将模块用作命名空间。这是关于类实例的类似物。

通过从全新{name: member}对象创建每个实例来创建的对象比使用new Classwith创建的对象效率低Class.prototype.name= member。在原型案例中，member值是共享的，从而产生更轻量级的实例。

在您的示例MNS中是单例，因此通过原型共享成员没有任何好处。

我不确定在上面的示例中是否创建了闭包

是的。即使在外部函数中没有定义变量，仍然会为外部函数创建一个 LexicalEnvironment 和范围对象，并在其中绑定this和arguments绑定。一个聪明的 JS 引擎可能能够优化它，因为每个内部函数都必须隐藏this并arguments使用它们自己的副本，但我不确定当前的任何 JS 实现是否真的这样做。

无论如何，性能差异应该是无法察觉的，因为您没有在参数中添加任何重要内容。对于一个简单的模块模式，我认为没有任何危害。

此外，您更喜欢使用哪些工具来获取有关执行时间、内存和 CPU 使用率的信息？

开始的地方只是在 for 循环中执行代码 10000 次，看看有多大new Date().getTime()，在尽可能多的不同浏览器上执行多次。

$(this).html().replace('[@]','@');

（这应该做什么？目前它会将 span 的 HTML 读入一个 new ，仅替换withString的第一个实例，并返回一个新值。它不会更改 DOM 中的现有内容。）[ @ ]@String

于 2010-03-04T09:00:23.550 回答
1

你有多少Javascript？根据我的经验，在页面上有大量Javascript 代码的网站上，性能问题通常来自实际执行操作的代码。通常，问题源于尝试做太多事情，或者尝试做某件特定的事情非常糟糕。一个例子是尝试将处理程序绑定到表行（大表）中的元素，而不是使用“实时”之类的东西。

我的观点是，您的模块或功能或任何组织方式几乎肯定不会在您的页面上造成任何类型的实际性能问题。是什么促使你去解决所有这些麻烦？

于 2010-03-04T13:30:58.937 回答