JavaScript constructor和instanceof,JSOO中的一对欢喜冤家

至少每个尝试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.而各自对另一个一笔带过或只字不提.怨念…甚深…