JavaScript constructor和instanceof,JSOO中的一对欢喜冤家_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也摒弃这对冤家吧.
类似今天这点事儿,老鸟们都清楚的很,但如果不是团队中每个人都有统一的认识,那就是隐患.
一个好玩儿的现象>强调instanceof,而>强调constructor.而各自对另一个一笔带过或只字不提.怨念..甚深...