定义类 - 不同的方法 [英] defining classes-- different methods
问题描述
有人可以解释这些创建
课程的不同方式的优缺点吗？
// 1
函数myclass（）{
this.foo1 = function（）{...}
}
// 2a
函数myclass（）{}
myclass.prototype.foo1 = function（）{...}
// 2b
函数myclass（）{}
myclass.prototype = {foo1：function（）{...}}
我很确定2a和2b是等价的 - 请告知这是不是很好。
我个人更喜欢方法1，因为它似乎允许公众的概念
和私人会员。例如，
函数myclass（）{
var privateVar =" hi"
function privateFn（）{return privateVar }
this.publicFn = function（）{return privateFn（）}
}
我的个人偏好除外，变化方法2似乎是标准的b $ b。有人可以告诉我为什么吗？有没有办法完成方法1的
方面我喜欢方法2？我觉得我很想念
a大创意：/
提前致谢...
Cliff
Cliff Williams写道：
有人可以解释这些不同方式的利弊
创建一个类？
// 1
函数myclass（）{
this.foo1 = function（）{...}
}
// 2a
function myclass（）{}
myclass.prototype.foo1 = function（）{...}
// 2b
function myclass（）{}
myclass.prototype = {foo1：function（）{...}}
我很确定2a和2b是等价的 - 请告知
如果这是不真实的。
它们等同于大多数实际用途，但是当创建函数
对象时，分配给其prototype属性的对象具有
对分配给它的函数的引用 - constructor - property，
这对于分配给
函数的prototype属性的对象是不正确的（除非明确编写脚本）。
对象的 - constructor - 属性几乎没有实际用途，因此两种
方法之间的区别很少显着。
还有一种情况是，当一个''类''继承自另一个'b
并且''supreclass''的实例分配给 - prototype -
属性时''子类'的''构造函数的值作为原型' -
构造函数 - 属性将再次不是对子类的引用
构造函数（除非明确编写脚本）。
我个人更喜欢方法1，因为它似乎允许公共和私人成员的概念。例如，
True，但请记住在
构造函数中指定的函数表达式将导致为<创建一个唯一的函数对象br />
使用构造函数创建的每个对象实例，而每个
实例在继承其
方法时继承对单个函数对象的引用构造函数引用的对象
原型因此，只要构造函数内部的对象方法将函数分配给函数，就会浪费资源
表达式。 >
不使用闭包来模仿私人会员。
function myclass（）{
var privateVar =" hi"
函数privateFn（）{return privateVar}
this.publicFn = function（）{return privateFn（）}
}
我的个人偏好除外，方法2的变化
见我要成为标准。有人可以告诉我为什么吗？
这是在javascript中进行继承的自然方式。使用
中的任何一个替代品（并且不仅仅是这三个）
应该是由
$ b $做出明智决定后的行动b程序员（也就是说，如果被问到应该可以清楚地说明为什么使用替代品来代替
，并列举其后的好处）。
有没有办法完成
方法1的各个方面我喜欢方法2？
是的。你就是这样做的;在
构造函数中分配的函数的引用将与从
原型继承的方法一起存在（除非它们的名称对应，在这种情况下
$ b在构造函数中分配的$ b方法掩盖了原型上的方法
（可能被认为是重载''supreclass''的方法）。
我觉得我好像
错过了一个大创意：/
你还没有说什么你如何看待你发布的代码是什么，所以无论你是否真的理解它是不可知的。
理查德。
啊...当我最初想到这个时我忘记了两点
是.prototype在继承中的作用以及函数
是对象的事实。
灯泡闪亮一点......感谢你的帮助。
Cliff Williams escreveu：
有人可以解释这些的利弊吗创建一个
类的不同方法？
// 1
函数myclass（）{
this.foo1 = function（）{...}
}
将事物分配给this在构造函数中应该是
初始化的一部分。所以分配静态如果你不打算关闭，那么函数对我来说没有意义
。
// 2a
函数myclass（）{}
myclass.prototype.foo1 = function（）{...}
// 2b
函数myclass（）{}
myclass.prototype = {foo1：function（）{...}}
它们相似，2b看起来比2a好，但改变了构造函数属性的预期
行为。
我个人更喜欢方法1，因为它似乎允许公共概念
和私人成员。例如，
函数myclass（）{
var privateVar =" hi"
function privateFn（）{return privateVar }
this.publicFn = function（）{return privateFn（）}
}
如果你不喜欢不需要封装变量，我没有看到使用它的意义：]
我的个人偏好除外，方法2的变化似乎是
标准。有人可以告诉我为什么吗？
你问为什么它是标准???如果是的话，因为这是唯一的
方式，我知道避免制作完全程序代码。
有没有办法完成
方法1的方面我喜欢方法2？我觉得我很想念
a Big Idea：/
嗯，我不喜欢这个词私人成员"在JavaScript中，你应该使用闭包作为一种技巧来存储函数内部的东西，而不需要将它们作为参数发送或创建新的类并存储
this内的数据。因此，如果你需要它，模拟＃1，
是没有意义的，使用它^^
-
Jonas Raoni Soares Silva
http://www.jsfromhell.com
Can someone explain the pros/cons of these different ways of creating a
class?
// 1
function myclass() {
this.foo1 = function() {...}
}
// 2a
function myclass() {}
myclass.prototype.foo1 = function() {...}
// 2b
function myclass() {}
myclass.prototype = { foo1: function() {...} }
I''m pretty sure 2a and 2b are equivalent-- please advise if this is
untrue.
I personally prefer method 1 since it seems to allow a notion of public
and private members. For example,
function myclass() {
var privateVar = "hi"
function privateFn() { return privateVar }
this.publicFn = function() { return privateFn() }
}
My personal preferences aside, the variations of method 2 seem to be
the standard. Can someone tell me why? Is there a way to accomplish the
aspects of method 1 I like with method 2? I sorta feel like I''m missing
a Big Idea :/
Thanks in advance...
Cliff
Cliff Williams wrote:Can someone explain the pros/cons of these different ways
of creating a class?
// 1
function myclass() {
this.foo1 = function() {...}
}
// 2a
function myclass() {}
myclass.prototype.foo1 = function() {...}
// 2b
function myclass() {}
myclass.prototype = { foo1: function() {...} }
I''m pretty sure 2a and 2b are equivalent-- please advise
if this is untrue.They are equivalent to most practical purposes, but when a function
object is created the object assigned to its prototype property has a
reference to the function assigned to its - constructor - property,
which is not true of an object assigned to the prototype property of a
function (unless explicitly scripted). The - constructor - property of
objects has little practical use so the distinction between the two
methods is rarely significant.
It is also the case that when one ''class'' inherits from another by
having and instance of the ''supreclass'' assigned to the - prototype -
property of the ''subclass'' s'' constructor the value as the prototype''s -
constructor - property will again not be a refernce to the subclass
constructor function (unless explicitly scripted).
I personally prefer method 1 since it seems to allow
a notion of public and private members. For example,True, but remember that a function expression assigned within the
constructor will result in a unique function object being created for
each and every object instance created with the constructor, while each
instance inherits a reference to a single function object when its
methods are inherited from the object referred to by the constructor''s
prototype Thus it is wasteful of resources to be assigning function
expressions to object methods inside the constructor whenever they are
not employing closures to emulate private members.
function myclass() {
var privateVar = "hi"
function privateFn() { return privateVar }
this.publicFn = function() { return privateFn() }
}
My personal preferences aside, the variations of method 2
seem to be the standard. Can someone tell me why?It is the natural way of doing inheritance in javascript. Using any of
the alternatives (and there are considerably more than just these three)
should be an action following from an informed decision by the
programmer (that is, if asked it should be possible to clearly state why
the alternative was used, and enumerate the benefits that follow).
Is there a way to accomplish
the aspects of method 1 I like with method 2?Yes. You just do it; the references to functions assigned in the
constructor will exist alongside the methods inherited from the
prototype (except where their names correspond, in which case the
methods assigned in the constructor mask the methods on the prototype
(which may be conceived as overloading the methods of a ''supreclass'')).
I sorta feel like I''m
missing a Big Idea :/You have not said anything about how you perceive what the code you
posted is doing, so whether you really understand it or not is
unknowable.
Richard.
Ah... two bits I forgot about when I was initially thinking about this
are the role of .prototype in inheritance and the fact that functions
are objects.
The lightbulb shines a little brighter... thanks for your help.
Cliff Williams escreveu:Can someone explain the pros/cons of these different ways of creating a
class?
// 1
function myclass() {
this.foo1 = function() {...}
}Assigning things to "this" in the constructor are supposed to be part of
the initialization. So assigning "static" functions doesn''t make sense
for me if you''re not going to make a closure.
// 2a
function myclass() {}
myclass.prototype.foo1 = function() {...}
// 2b
function myclass() {}
myclass.prototype = { foo1: function() {...} }They are similar, 2b looks better than 2a, but changes the "expected"
behavior of the constructor property.
I personally prefer method 1 since it seems to allow a notion of public
and private members. For example,
function myclass() {
var privateVar = "hi"
function privateFn() { return privateVar }
this.publicFn = function() { return privateFn() }
}If you don''t need to encapsulate variables, I don''t see a point to use it :]
My personal preferences aside, the variations of method 2 seem to be
the standard. Can someone tell me why?You''re asking why it''s the standard??? If yes, because this is the only
way I know to avoid making totally procedural codes.
Is there a way to accomplish the
aspects of method 1 I like with method 2? I sorta feel like I''m missing
a Big Idea :/Hmmm, I don''t like the term "private members" in JavaScript, you should
use the closures as a trick to store things inside the functions without
the need of sending them as arguments or creating new classes and store
the data inside the "this". So, there''s no point in simulating the #1,
if you need it, use it ^^
--
Jonas Raoni Soares Silva
http://www.jsfromhell.com
这篇关于定义类 - 不同的方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
