JavaScript constructor and instanceof, a pair of happy enemies in JSOO_javascript skills

At least every programmer who tries JavaScriptOO spends a lot of energy on the simulation of the object-oriented mechanism rather than the business itself.
This is unimaginable for developers of Java, C and even Php.
More The bad thing is that simulating OO has an evil attraction for advanced JavaScript programmers.
Because doing this thing is transcendent from business, there is a kind of pleasure of creating a new programming language, which can make your IQ flourish.
Just like In the past few years, everyone wanted to write the common.js of their website as a framework. It was not until the strong launch of YUI, JQuery, etc. that it calmed down a little.
However, although each framework has JavaScriptOO simulation, it has not yet arrived. When someone can make a bucket of paste.
Maybe there will be no unnecessary overlord in the world, or everyone just needs to wait until JS2.0.
If new means object-oriented, then obviously JavaScript is here The aspect is very good.

Copy code The code is as follows:

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);

So far, everything is harmonious.
The constructor of the object points to the constructor literally. Its Person.
The object is an instance of the Person that constructed it.
All objects are instances of Object, just like Java.
JavaScript provides a prototype way to implement methods Extension and inheritance

Copy code The code is as follows:

Person.prototype.getName = function() {
return this.name
};

After this definition, all objects have the getName method.
Of course, it can also be written in the object construction

Copy code The code is as follows:

function Person(name){
this.name = name;
this.getName = function(){
return this.name;
};
}

But this approach not only brings additional performance loss The flaw is not only the privilege of accessing private variables.
It is also different from the way of writing using prototype, but this is not the focus of this article.
Next, we think of inheritance, which is very The common way to write it is like this.

Copy code The code is as follows:

function Stuff(name, id){
this.name = name;
this.id = id;
}
Stuff.prototype = new Person();
var piupiu = new Stuff("piupiu", "007");
alert(piupiu.getName());

Very good, it inherits the getName method;
Check instanceof

Copy code The code is as follows:

alert(piupiu instanceof Stuff === true);
alert(piupiu instanceof Person === true);

Very good, it shows that Stuff and Person are related. piupiu is an instance of them, very Java.
Let’s examine the constructor

Copy code The code is as follows:

alert(piupiu.constructor === Stuff);//false
test (piupiu.constructor === Person);//true

The question arises why the constructor of new Stuff is Person.
The reason here is also unreasonable, we have to remember Conclusion
Conclusion: The constructor attribute of an object does not point to its constructor, but the constructor attribute of the prototype attribute of its constructor
My writing skills are so poor that I didn’t think it was clear even after I read it
Put it here :
The constructor property of the object piupiu points to the constructor property of the prototype property of its constructor Stuff
Because Stuff.prototype = new Person();
So Stuff.prototype.constructor === Person.
So piupiu.consturctor === Person.
The above conclusion does not only appear when objects are inherited, but also when defining objects

Copy code The code is as follows:

function Student(name){
this.name = name;
}
Student.prototype = {
getName :function(){
return this.name;
},
setName:function(name){
this.name = name;
}
}

메서드가 많으면 이렇게 작성하는 경우가 더 규칙적으로 보입니다.
실제로 이런 작성 방식은 생성자를 희생하기도 합니다

코드 복사 코드는 다음과 같습니다.

var moen = new Student("moen")
alert(moen.constructor === Student) ;//false
alert( moen.constructor === Object);//true

{}는 new Object()와 동일하므로 위 결론에 따르면 프로토타입이 ={}, 생성자가 변경됩니다.
생성자를 보호합니다! 상속 시 루프를 사용하여 상위 클래스의 메서드를 하위 클래스에 복사합니다.

코드 복사 코드는 다음과 같습니다.

function Stuff1(name,id){
this.name = name; >}
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);


작동합니다! 행복하게 부모 클래스의 모든 메서드를 상속받으면 부모-자식 관계가 끊어집니다.

코드 복사 코드는 다음과 같습니다. :

alert(piupiu1 인스턴스of Stuff1 == = true);//true

alert(piupiu1 인스턴스of Person === true);//false


분명히 Stuff1이 Person으로부터 상속받았다고 말하지 않았는데, for 루프만 있다는 게 무슨 뜻일까요?

이것은 모순인 것 같습니다.
그래서. , 객체를 깊이있게 사용하면 조심하지 않아도 instantceof와 생성자가 문자 그대로의 의미를 잃게 됩니다.
따라서 프레임워크를 사용할 때 상속 기능이 제공되면 어떤 것을 사용하는지 알 수 없습니다.
그래서 OO를 시뮬레이션할 때는 이 두 리터럴에 대한 대안을 제공해야 합니다.
OO를 시뮬레이션하려면 속성이나 메서드 구현의 의미를 알아야 합니다. 이는 확실히 이 문제에 국한되지 않습니다. 하위 클래스 메서드에서 동일한 이름으로 부모 클래스의 메서드를 호출하는 것은 OO 언어의 일반적인 기능입니다.
JS도 기본적으로 매우 어렵습니다. 그러나 Base 라이브러리와 같이 신중하게 수행하면 사용하기가 더 자연스럽습니다.
물론, instanceof 및 생성자의 사용을 포기할 수 있으며, 그런 것이 있다는 것을 알면 됩니다. 그래도 일은 계속할 수 있고 아무도 죽지 않을 것입니다.
그러나 혼자 싸우는 것이 아니라면 파트너에게 이 두 명의 적들을 버리라고 알리십시오.
오늘의 요점과 유사하게 참전용사들은 이것을 잘 알고 있습니다. 그러나 팀의 모든 사람이 통일된 이해를 갖고 있지 않다면
흥미로운 현상은> 을 강조하고 > 그리고 둘은 서로를 그냥 무시하거나 전혀 언급하지 않습니다. 그 원한은 매우 깊습니다.