JavaScript コンストラクターと instanceof、JSOO_javascript スキルにおける幸せな敵のペア

少なくとも、JavaScriptOO を試すすべてのプログラマは、ビジネスそのものではなく、オブジェクト指向メカニズムのシミュレーションに多くのエネルギーを費やします。
これは、Java、C、さらには Php の開発者にとっては想像もつかないことです。
さらに悪いことです。 OO のシミュレーションは、上級 JavaScript プログラマにとって邪悪な魅力を持っているということです。
これを行うことはビジネスの枠を超えているため、新しいプログラミング言語を作成するという一種の喜びがあり、それによって IQ が向上します。
と同じです。ここ数年、誰もが Web サイトの common.js をフレームワークとして書きたがっていましたが、それが少し落ち着いたのは、YUI や JQuery などが登場してからです。
ただし、それぞれのフレームワークは異なります。 JavaScriptOO シミュレーションはまだ到着していません。
おそらく世界中に不要なオーバーロードは存在しないでしょう。そうでない場合は、JS2.0 まで待つ必要があります。
オブジェクト指向なので、当然 JavaScript が登場します。この側面は非常に優れています。

コードをコピー コードは次のとおりです。

function person(name){
this.name = name;
var lenel = new person("lenel")
alert(lenel.constructor ===)人);
alert(lenelinstanceofObject ===true);


これまでのところ、すべては調和しています。オブジェクトのコンストラクターは文字通りコンストラクターを指します。

オブジェクトはそれを構築したインスタンスです。
JavaScript がプロトタイプを提供するのと同じです。メソッドの実装方法 拡張と継承




コードをコピー

コードは次のとおりです。人物。 prototype.getName = function() { return this.name

};

この定義の後、すべてのオブジェクトが getName メソッドを持つようになります。
もちろん、これも可能です。オブジェクト構造に書かれています

コードをコピー

コードは次のとおりです:function person(name ){ this.name = name;

this.getName = function(){

return this.name>}


これこのアプローチは追加のパフォーマンス損失をもたらすだけではありません。この欠陥はプライベート変数へのアクセス権限だけではありません。
プロトタイプを使用した記述方法とも異なりますが、これはこの記事の焦点では​​ありません。
次に、一般的な書き方は次のとおりです。

コードをコピー

コードは次のとおりです。 🎜>function Stuff(name, id){ this.name = name; this.id = id; } Stuff.prototype = new Person();

var piupiu = new Stuff("piupiu", "007");

alert(piupiu.getName());


これは getName メソッドを継承しています。 >インスタンスのチェック




コードをコピー

コードは次のとおりです:

alert(piupiuinstanceof Stuff = == true); alert(piupiu instanceof Person === true); 非常に優れており、piupiu がそれらのインスタンスであることを示しています。まさに Java です。 コンストラクターを調べてみましょう

コードをコピーします

コードは次のとおりです。

alert( piupiu.constructor === Stuff);//false test (piupiu.constructor === person);//trueなぜ新しい Stuff のコンストラクターが person なのかという疑問が生じます。 ここでの理由も不合理なので、覚えておく必要があります。 結論

結論: オブジェクトのコンストラクタ属性は、そのコンストラクタを指しているのではなく、そのコンストラクタのプロトタイプ属性のコンストラクタ属性を指しています。

私の文章力あまりにも貧弱なので、読んでもよく理解できなかった
ここに入れてください:
オブジェクト piupiu のコンストラクター プロパティは、そのコンストラクターのプロトタイプ プロパティのコンストラクター プロパティを指します。 Stuff
Stuff.prototype = new Person();

だから Stuff.prototype.constructor === person
だから piupiu.constructor
上記の結論は、オブジェクトが継承された場合にのみ現れるわけではありません。 、オブジェクトを定義するときも同様です




コードをコピー


コードは次のとおりです。

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

setName :function(name){

this.name = name;
}


If there are many methods, they are often written like this, which looks more regular.
In fact, this way of writing also sacrifices the constructor

Copy code The code is as follows:

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

Because {} is equivalent to new Object(), so according to the above conclusion, when prototype={}, the constructor changes.
Defend the constructor! When inheriting, we use a loop to copy the parent class's method to the subclass

Copy code The code is as follows:

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! When we happily inherit all the methods of the parent class, we The parent-child relationship is lost.

Copy code The code is as follows:

alert(piupiu1 instanceof Stuff1 == = true);//true
alert(piupiu1 instanceof Person === true);//false

Obviously, we did not say that Stuff1 is inherited from Person, there is only a for loop What can it mean?
This seems to be a contradiction. If you focus on one, you will lose the other.
So, when you use objects in depth, even if you are not careful, instantceof and constructor will lose their literal meaning. .
So, when using a framework, if the inheritance function is provided, you won’t know which one you gave up for inheritance if you don’t try it.
So, when simulating OO, you must provide alternatives to these two literals. The meaning of the implementation of attributes or methods must be known to users!
Simulating OO is definitely not limited to this problem. Calling the method of the parent class with the same name in a subclass method is a common feature of OO languages.
JS can be implemented It is also very difficult. The masters basically have their own methods, but some are more natural to use if they are done carefully, such as the Base library.
Of course, you can abandon the use of instanceof and constructor, just treat it as if it is not Knowing that there is such a thing, the work can still go on and no one will die.
But if you are not fighting alone, then inform your partner to abandon this pair of enemies.
Similar to today's point Veterans know this very well, but if not everyone in the team has a unified understanding, there is a hidden danger.
An interesting phenomenon<> emphasizes instanceof , and <> emphasizes constructor. And each of them just brushes off or doesn't mention the other at all. The resentment is very deep...