下划线 bindAll，显式方法命名答案

【问题标题】：Underscore bindAll, explicit method naming下划线 bindAll，显式方法命名
【发布时间】：2012-02-07 11:37:06
【问题描述】：

我在我的许多 Backbone.Views 中使用_.bindAll。

_.bindAll(this, 'render', 'addOne', 'addAll', 'someFunctionA', 'someFunctionB');

虽然重构这变得相当乏味，因为我需要保持视图方法和名称列表同步。这两种方式都经常导致简单的错误。

由于bindAll 有一个简短版本，它可以消除这种需求，我想知道确实存在哪些缺点（性能、可读性、灵活性……），你认为它们是否可以接受以获得一点生产力提升。

_.bindAll(this);

【问题讨论】：

标签： javascript coding-style backbone.js underscore.js

【解决方案1】：

使用这种形式的 bindAll 并没有实际的性能损失。但是，如果您出于某种原因不希望将方法绑定到 this，那将会很痛苦。

但是，您可能会发现您不需要像您想象的那样经常使用 bindAll。所有绑定到事件处理程序（带有事件哈希）的方法都会自动绑定到this。

此外，当您显式绑定事件时，您可以在第三个参数中传递 this 绑定。例如：

this.model.bind('change', this.render, this)

【讨论】：

谢谢。我的使用量增加是由于应用程序范围的 eventBus，其中没有自动绑定：/ Thx 指出绑定 this，直接在我声明模型绑定时（注意：我认为它应该读作：this.model.on ）。最后，我很好奇：在哪些情况下，我不希望我的视图方法绑定到视图本身？
对，Backbone 0.9 现在使用“on”而不是 0.5 及之前的“bind”。在“视图世界”中，我发现您几乎总是希望 this 成为视图。但是，如果您真的依附于 this 作为事件目标的 jQuery 约定，那么这可能不适合您。就个人而言，我喜欢this 使用的一致性。

【解决方案2】：

我在骨干项目中使用_.bindAll(this) 有一段时间了。分析代码后，我意识到对 _.bindAll 的调用占所有函数调用的显着部分。
基于性能测试结果http://jsperf.com/underscore-bindall-this-vs-bindall-this-params 似乎显式方法命名更高效（特别是对于具有很多功能的对象）

【讨论】：