如果您需要创建大量的方法,那么将原型用于方法是有好处的,当您使用接近“this”的方法创建对象时,您是否会获得相同的效果和好处在构造函数中?
请参阅以下代码:
(function(){
var Planet = function(){
var self = this;
var API = {
publicInterfaceMethodA:function(){
self.privateProtoMethodA();
},
publicInterfaceMethodB:function(){}
};
return API;
};
Planet.prototype = {
privateProtoMethod:function(){ },
privateProtoMethodA:function(){ },
privateProtoMethodB:function(){ },
privateProtoMethodC:function(){ },
privateProtoMethodD:function(){ },
privateProtoMethodE:function(){ }
};
var mars = new Planet();
}());
假设我在原型上有100个“private”方法,对于我创建的每个实例,我只想暴露这些少数公共api方法,但我想保留使用原型的好处对于内部方法,以便我不为每个创建的实例“复制”100个方法到“this”。
从我所看到的,这不是人们通常如何做到的,我在这里遗漏了什么,或者如果没有在构造函数中返回“this”并暴露整个原型,你会获得相同的好处吗? ?
由于
答案 0 :(得分:1)
当我开始认真开发JS时,我也经常使用var self = this;
,因为我已经习惯了各种jQuery教程,我也尝试过你的方法和其他模拟私有方法。
我个人不喜欢这两个。
虽然mars
确实不是Planet
的实例,但在我看来,这不是一个真正的问题,因为我通常会测试api功能,而不是经常测试对象是一个实例某个构造函数。
私人方法/成员:当你的项目增长并变大时,你可能想开始进行单元测试。如果你是拥有100
私有方法和仅 10
公共方法,创建良好的单元测试可能会成为真正的问题。对于单元测试,您希望测试尽可能少的依赖性。
这就是为什么我改变了主意,并希望用jsdoc创建一个明确的api文档,使用注释标记方法/成员,如果它们是私有的,而不是没有真正隐藏它们。
有时它不仅可以根据情况替换公共方法,还可以用于私有方法。
对于您的方法肯定有效的情况,但如果只是使用它来保护函数不被滥用,您可能应该考虑它。
致var self = this;
:只要someFunction.bind(element)
没有产生性能问题,我就更喜欢使用bind
(旧浏览器有polyfill)。有了它,你可以避免例如深度嵌套回调并且您无需记住,您需要使用{em>期望关键字为self
的{{1}}。
答案 1 :(得分:0)
这样的事情怎么样?
(function(){
var Planet = function(){
var self = this;
self.constructor.methods = {
A: function(){ console.log('Constructor Method A called'); },
B: function(){ },
C: function(){ },
D: function(){ },
E: function(){ }
};
var API = {
publicInterfaceMethodA: function(){
return self.constructor.methods.A.call(this);
},
publicInterfaceMethodB: function(){}
};
return API;
};
var mars = new Planet();
mars.publicInterfaceMethodA();
}());
方法附加到Planet
函数,然后由mars
实例调用。