正如其他人所说:这个“额外变量”是(在某种程度上)获得this
特殊表达式这一事实的唯一方法,因此,它不是变量,不受执行上下文/闭包的约束。
但是,我认为您要问的(或我真正想回答的)是:
应该放在var self = this
每个方法/构造函数的顶部吗?
概括
虽然我试过一次,并有同样的问题,但我不再使用这种方法。现在,我保留该构造以供需要在闭包中访问时使用。对我来说,它增加了一点“嘿,这就是我真正想要的!” 我的代码的语义:
this -> this
和 self -> this (but really that) in a closure
单点问题:
……虽然这是常用的做法,但感觉有点不对。我希望在这个问题中找到一种更好的方法来解决这个问题,或者让我相信这是很好的。
做你认为正确的事情。不要害怕尝试一种方法并稍后切换回来(但请尝试在每个项目中保持一致:-)
这是保持正确绑定的标准方法吗?除非我明确需要“this”,否则我是否应该标准化在任何地方使用“self”。
“self”是最常用的名称。如上所述,我更喜欢相反的方法——this
除非需要闭包绑定,否则使用。
..如果它被认为有点邪恶,为什么。
邪恶是一个愚蠢的主观术语(尽管有时很有趣)。我从来没有说过这是邪恶的,这就是为什么我不遵循这种方法。有些人告诉我我不使用分号是“邪恶的”。我告诉他们他们应该提出好的论据和/或更好地学习 JavaScript :-)
我知道还有“应用”内置 javascript 函数可以在调用方法时显式定义范围。这个会比较好吗?
问题apply/call
在于您必须在函数调用时使用它们。如果其他人调用您的方法之一,这将无济于事,因为它this
可能已经关闭。它对于执行诸如 jQuery 样式的回调之类的事情最有用,其中this
是回调的元素/项目等。
作为旁白...
我喜欢避免成员“需要自我”,因此通常将所有成员函数提升为接收者 ( this
) 只是“流经”的属性,这通常是“如预期的”。
我的代码中的“私有”方法以“_”开头,如果用户调用它们,那就是它们。当使用原型方法创建对象时,这也更有效(确实是必需的)。但是,Douglas Crockford 不同意我的这种“私有”方法,并且在某些情况下,查找链可能会通过注入意外接收器来阻止您:
在构造函数中使用“self”绑定也会锁定一个方法的查找链的上限(它不再是向上多态的!),这可能正确也可能不正确。我认为这通常是不正确的。
快乐编码。