JavaScript constructor和instanceof,JSOO中的一对欢喜冤家
更新时间:2009年05月25日 02:55:12 作者:
现在流行面向对象,JavaScript当然要迎头赶上.
有说法JavaScript就是彻头彻尾的OO语言,但我觉得JavaScript实现面向对象的程序还是有诸多不便的.
至少每个尝试JavaScriptOO的程序员都花费很多精力用在面向对象机制的模拟上而非业务本身.
这对Java,C++甚至Php的开发者来讲都是难以想象的.
更糟糕的是模拟OO对于JavaScript高级程序员都有着邪恶的吸引.
因为干这个事儿超然于业务之上,有种创造新编程语言一般的快感,可以令IQ尽情挥洒.
正如前些年大家都想把自个网站的common.js写成个框架一样.直到YUI,JQuery等等的强势推出才稍有平息.
然而虽然各个框架都有对JavaScriptOO模拟,但还未到有谁谁谁可以一桶糨糊的时候吧.
或许江湖就不需要的霸主出现,抑或大家只要等到JS2.0+就好了.
如果说可以new就是面向对象,那显然JavaScript在这方面是非常不错的.
function Person(name){
this.name = name;
}
var lenel = new person("lenel");
alert(lenel.constructor === Person);
alert(lenel instanceof Person === true);
alert(lenel instanceof Object === true);
到此为止,一切都很和谐.
对象的constructor正如字面上的意义指向构造它的Person.
对象是构造它的Person的一个实例(instance).
所有对象都是Object的实例,像极了Java.
JavaScript提供原型(prototype)的方式来实现方法拓展和继承
Person.prototype.getName = function(){
return this.name
};
这样定义了之后所有对象都具有了getName的方法.
当然也可以将写在对象构造时
function Person(name){
this.name = name;
this.getName = function(){
return this.name;
};
}
但是这种做法不仅是带来额外性能损耗这点瑕疵,也不仅是带来了可以访问私有变量的特权.
它与使用prototype的写法还会其他有不同之处,不过这不是本文的重点.
接下来,我们想到继承,很常见的写法是这样的.
function Stuff(name,id){
this.name = name;
this.id = id;
}
Stuff.prototype = new Person();
var piupiu = new Stuff("piupiu","007");
alert(piupiu.getName());
非常好,继承了getName方法;
考察下instanceof
alert(piupiu instanceof Stuff === true);
alert(piupiu instanceof Person === true);
非常好,说明了Stuff和Person是有关系的.piupiu是它俩的实例,非常Java.
接下来再考察下constructor
alert(piupiu.constructor === Stuff);//false
test(piupiu.constructor === Person);//true
问题出现了明明new的Stuff为啥constructor却是Person,
在这儿将道理也是强词夺理,我们只好记住结论
结论:对象的constructor属性并非指向其构造器,而是指向其构造器的prototype属性的constructor属性
文字功底太差,自己读过都觉得没说清楚
放在这里:
对象piupiu的constructor属性指向的是其构造器Stuff的prototype属性的constructor属性
因为Stuff.prototype = new Person();
所以Stuff.prototype.constructor === Person.
所以piupiu.consturctor === Person.
以上的结论不仅仅在对象继承的时候才出现,在定义对象时
function Student(name){
this.name = name;
}
Student.prototype = {
getName:function(){
return this.name;
},
setName:function(name){
this.name = name;
}
}
如果方法比较多,常常会这样写,看起来规矩一些.
其实这种写法同样牺牲了constructor
var moen = new Student("moen");
alert(moen.constructor === Student);//false
alert(moen.constructor === Object);//true
因为在{}相当于new Object(),所以根据上面的结论prototype={}时,constructor变了.
保卫constructor!继承时我们用一个循环来把父类的方法copyto子类
function Stuff1(name,id){
this.name = name;
this.id = id;
}
for(var fn in Person.prototype){
Stuff1.prototype[fn] = Person.prototype[fn];
}
var piupiu1 = new Stuff1("piupiu1","008");
alert(piupiu1.getName() === "piupiu1");
alert(piupiu1.constructor === Stuff1);
It works!当我们兴冲冲的把父类的方法都继承下来的时候,我们却丢失了父子关系.
alert(piupiu1 instanceof Stuff1 === true);//true
alert(piupiu1 instanceof Person === true);//false
显然,我们没有说过Stuff1是继承至Person啊,只一个for循环能说明什么呢.
这好像是一对矛盾..顾此必失彼.
所以叻,深入使用对象的时候,甚至你一不小心,都会让instantceof和constructor丢去字面的含义.
所以叻,在使用框架的时候,如果提供了继承功能,如果不试不会知道你为了继承放弃了哪个.
所以叻,模拟OO时就必须要提供替代这两个字面含义的属性或方法的实现,而且必须让使用者知道!
模拟OO绝对不只这个问题,在子类方法中调用父类的同名方法,这个OO语言常见的特性,
JavaScript实现起来也非常困难,大师们基本都有各自的一套,只不过有些用心去做了用起来相比之下更自然些,如Base库.
当然可以摒弃instanceof和constructor的使用,就当不知道有这么一回儿事儿,活儿仍可继续,死不了人的.
但如果你不是单枪匹马作战,那就通知你的Partner也摒弃这对冤家吧.
类似今天这点事儿,老鸟们都清楚的很,但如果不是团队中每个人都有统一的认识,那就是隐患.
一个好玩儿的现象<<JavaScript高级程序设计>>强调instanceof,而<<精通JavaScript>>强调constructor.而各自对另一个一笔带过或只字不提.怨念..甚深...
这对Java,C++甚至Php的开发者来讲都是难以想象的.
更糟糕的是模拟OO对于JavaScript高级程序员都有着邪恶的吸引.
因为干这个事儿超然于业务之上,有种创造新编程语言一般的快感,可以令IQ尽情挥洒.
正如前些年大家都想把自个网站的common.js写成个框架一样.直到YUI,JQuery等等的强势推出才稍有平息.
然而虽然各个框架都有对JavaScriptOO模拟,但还未到有谁谁谁可以一桶糨糊的时候吧.
或许江湖就不需要的霸主出现,抑或大家只要等到JS2.0+就好了.
如果说可以new就是面向对象,那显然JavaScript在这方面是非常不错的.
复制代码 代码如下:
function Person(name){
this.name = name;
}
var lenel = new person("lenel");
alert(lenel.constructor === Person);
alert(lenel instanceof Person === true);
alert(lenel instanceof Object === true);
到此为止,一切都很和谐.
对象的constructor正如字面上的意义指向构造它的Person.
对象是构造它的Person的一个实例(instance).
所有对象都是Object的实例,像极了Java.
JavaScript提供原型(prototype)的方式来实现方法拓展和继承
复制代码 代码如下:
Person.prototype.getName = function(){
return this.name
};
这样定义了之后所有对象都具有了getName的方法.
当然也可以将写在对象构造时
复制代码 代码如下:
function Person(name){
this.name = name;
this.getName = function(){
return this.name;
};
}
但是这种做法不仅是带来额外性能损耗这点瑕疵,也不仅是带来了可以访问私有变量的特权.
它与使用prototype的写法还会其他有不同之处,不过这不是本文的重点.
接下来,我们想到继承,很常见的写法是这样的.
复制代码 代码如下:
function Stuff(name,id){
this.name = name;
this.id = id;
}
Stuff.prototype = new Person();
var piupiu = new Stuff("piupiu","007");
alert(piupiu.getName());
非常好,继承了getName方法;
考察下instanceof
复制代码 代码如下:
alert(piupiu instanceof Stuff === true);
alert(piupiu instanceof Person === true);
非常好,说明了Stuff和Person是有关系的.piupiu是它俩的实例,非常Java.
接下来再考察下constructor
复制代码 代码如下:
alert(piupiu.constructor === Stuff);//false
test(piupiu.constructor === Person);//true
问题出现了明明new的Stuff为啥constructor却是Person,
在这儿将道理也是强词夺理,我们只好记住结论
结论:对象的constructor属性并非指向其构造器,而是指向其构造器的prototype属性的constructor属性
文字功底太差,自己读过都觉得没说清楚
放在这里:
对象piupiu的constructor属性指向的是其构造器Stuff的prototype属性的constructor属性
因为Stuff.prototype = new Person();
所以Stuff.prototype.constructor === Person.
所以piupiu.consturctor === Person.
以上的结论不仅仅在对象继承的时候才出现,在定义对象时
复制代码 代码如下:
function Student(name){
this.name = name;
}
Student.prototype = {
getName:function(){
return this.name;
},
setName:function(name){
this.name = name;
}
}
如果方法比较多,常常会这样写,看起来规矩一些.
其实这种写法同样牺牲了constructor
复制代码 代码如下:
var moen = new Student("moen");
alert(moen.constructor === Student);//false
alert(moen.constructor === Object);//true
因为在{}相当于new Object(),所以根据上面的结论prototype={}时,constructor变了.
保卫constructor!继承时我们用一个循环来把父类的方法copyto子类
复制代码 代码如下:
function Stuff1(name,id){
this.name = name;
this.id = id;
}
for(var fn in Person.prototype){
Stuff1.prototype[fn] = Person.prototype[fn];
}
var piupiu1 = new Stuff1("piupiu1","008");
alert(piupiu1.getName() === "piupiu1");
alert(piupiu1.constructor === Stuff1);
It works!当我们兴冲冲的把父类的方法都继承下来的时候,我们却丢失了父子关系.
复制代码 代码如下:
alert(piupiu1 instanceof Stuff1 === true);//true
alert(piupiu1 instanceof Person === true);//false
显然,我们没有说过Stuff1是继承至Person啊,只一个for循环能说明什么呢.
这好像是一对矛盾..顾此必失彼.
所以叻,深入使用对象的时候,甚至你一不小心,都会让instantceof和constructor丢去字面的含义.
所以叻,在使用框架的时候,如果提供了继承功能,如果不试不会知道你为了继承放弃了哪个.
所以叻,模拟OO时就必须要提供替代这两个字面含义的属性或方法的实现,而且必须让使用者知道!
模拟OO绝对不只这个问题,在子类方法中调用父类的同名方法,这个OO语言常见的特性,
JavaScript实现起来也非常困难,大师们基本都有各自的一套,只不过有些用心去做了用起来相比之下更自然些,如Base库.
当然可以摒弃instanceof和constructor的使用,就当不知道有这么一回儿事儿,活儿仍可继续,死不了人的.
但如果你不是单枪匹马作战,那就通知你的Partner也摒弃这对冤家吧.
类似今天这点事儿,老鸟们都清楚的很,但如果不是团队中每个人都有统一的认识,那就是隐患.
一个好玩儿的现象<<JavaScript高级程序设计>>强调instanceof,而<<精通JavaScript>>强调constructor.而各自对另一个一笔带过或只字不提.怨念..甚深...
您可能感兴趣的文章:
- js constructor的实际作用分析
- Javascript的构造函数和constructor属性
- 理解Javascript_11_constructor实现原理
- 深入分析js中的constructor和prototype
- JavaScript类和继承 constructor属性
- JavaScript中几个重要的属性(this、constructor、prototype)介绍
- JavaScript中的prototype和constructor简明总结
- javascript new后的constructor属性
- 不用构造函数(Constructor)new关键字也能实现JavaScript的面向对象
- javascript设计模式Constructor(构造器)模式
相关文章
javascript实现选中复选框后相关输入框变灰不可用的方法
这篇文章主要介绍了javascript实现选中复选框后相关输入框变灰不可用的方法,涉及javascript针对页面元素属性的相关操作技巧,具有一定参考借鉴价值,需要的朋友可以参考下2015-08-08深入理解JavaScript系列(27):设计模式之建造者模式详解
这篇文章主要介绍了深入理解JavaScript系列(27):设计模式之建造者模式详解,建造者模式可以将一个复杂对象的构建与其表示相分离,使得同样的构建过程可以创建不同的表示,需要的朋友可以参考下2015-03-03使用js判断数组中是否包含某一元素(类似于php中的in_array())
这篇文章主要是对使用js判断数组中是否包含某一元素(类似于php中的in_array())需要的朋友可以过来参考下,希望对大家有所帮助2013-12-12document.getElementById为空或不是对象的解决方法
document.getElementById为空或不是对象的解决方法,一般情况下注意先内容后js.2010-01-01
最新评论