적어도 JavaScriptOO를 시도하는 모든 프로그래머는 비즈니스 자체보다는 객체 지향 메커니즘의 시뮬레이션에 많은 에너지를 소비합니다.
이것은 Java, C, 심지어 Php 개발자에게도 상상할 수 없는 일입니다.
더 나쁜 점은 다음과 같습니다. OO를 시뮬레이션하는 것은 고급 JavaScript 프로그래머에게 사악한 매력을 가지고 있다는 것입니다.
이 작업을 수행하는 것은 비즈니스를 초월하기 때문에 IQ를 향상시킬 수 있는 새로운 프로그래밍 언어를 만드는 일종의 즐거움이 있습니다.
지난 몇 년 동안 모든 사람들은 자신의 웹사이트의 common.js를 프레임워크로 작성하고 싶었습니다. YUI, JQuery 등이 출시되기 전까지는
그러나 각 프레임워크는 다소 진정되었습니다. JavaScriptOO 시뮬레이션이 아직 도착하지 않았습니다.
세상에 불필요한 대군주가 없을 수도 있고, 아니면 모두가 JS2.0까지 기다려야 할 수도 있습니다.
새로운 방법이 있다면. 객체지향이라면 당연히 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);
지금까지 모든 것이 조화를 이루고 있습니다. 객체의 생성자는 말 그대로 생성자를 가리킵니다.
객체는 이를 생성한 Person의 인스턴스입니다.
JavaScript가 프로토타입을 제공하는 것과 마찬가지로 모든 객체는 Object의 인스턴스입니다. 메소드 구현 방법 확장 및 상속
Person. 프로토타입.getName = function() {
return this.name
};
이 정의 이후에는 모든 객체에 getName 메서드가 있습니다.
물론 그럴 수도 있습니다. 객체 구성에 적힌
function Person(name ){
this.name = name;
this.getName = function(){
return this.name;
}
하지만 접근 방식은 추가 성능 손실을 가져올 뿐만 아니라 전용 변수에 액세스할 수 있는 권한만 있는 것이 아닙니다.
프로토타입을 사용하여 작성하는 방식과도 다르지만 이것이 이 글의 초점은 아닙니다
다음으로 설명하겠습니다. 상속을 생각해 보세요. 일반적인 작성 방법은 다음과 같습니다.
this.name = name;
this.id = id
}
Stuff.prototype = new Person();
var piupiu = new Stuff("piupiu", "007");
alert(piupiu.getName());
아주 좋습니다. getName 메소드를 상속합니다. >인스턴스 확인
코드 복사
코드는 다음과 같습니다.alert(piupiu instanceof Stuff = == true); alert(piupiu instanceof Person === true);
매우 좋습니다. piupiu가 매우 Java와 관련되어 있음을 보여줍니다.
생성자를 살펴보겠습니다
코드 복사
코드는 다음과 같습니다.alert( piupiu.constructor === Stuff);//false test (piupiu.constructor === Person);//true
new Stuff의 생성자가 왜 Person인지 의문이 생깁니다.
이것도 말도 안 되는 이유입니다. 결론을 기억해야 합니다
결론: 객체의 생성자 속성은 생성자를 가리키는 것이 아니라 객체 생성자의 프로토타입 속성의 생성자 속성을 가리킵니다.
나의 글쓰기 실력 너무 형편없어서 읽어도 명확하지 않다고 생각했습니다
여기에 넣으세요:
객체 piupiu의 생성자 속성은 해당 생성자의 프로토타입 속성인 생성자 속성을 가리킵니다 Stuff
Stuff.prototype = new Person();
그래서 Stuff.prototype.constructor === Person.
그래서 piupiu.consturctor === Person
위의 결론은 객체가 상속될 때만 나타나는 것이 아닙니다. , 객체를 정의할 때도
코드 복사
}
Student.prototype = {
getName :function(){
return this.name; :함수(이름){
this.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 및 생성자의 사용을 포기할 수 있으며, 그런 것이 있다는 것을 알면 됩니다. 그래도 일은 계속할 수 있고 아무도 죽지 않을 것입니다.
그러나 혼자 싸우는 것이 아니라면 파트너에게 이 두 명의 적들을 버리라고 알리십시오.
오늘의 요점과 유사하게 참전용사들은 이것을 잘 알고 있습니다. 그러나 팀의 모든 사람이 통일된 이해를 갖고 있지 않다면
흥미로운 현상은<
> 을 강조하고 <> 그리고 둘은 서로를 그냥 무시하거나 전혀 언급하지 않습니다. 그 원한은 매우 깊습니다.