Clever Geek Handbook

レガシーまたは継承：.prototypeについてのちょっとしたトピック、新入生のしゃれ

私は信じられないほど簡潔にしようとします。



始めたばかりの人のために書かれています！



JSの継承に関する記事はありません。





ネイティブスピーカーのレベルで用語の違いがあることを追加することが重要だと思います。 -英語。 そしてこれは、JSでプロトタイプを操作する場合に基本的に重要です。



Googleのクエリ「 継承とレガシーの違い 」では、最初のリンクがここにあります： link



言うまでもなく、記事は1つもありません。



そのような行があります、付録： また、いくつかのコメントで指摘されているように、「継承」は一般に受信者の観点から、「レガシー」は贈与者の観点からです：私の継承は父の遺産でした。



簡単な点は、私が自分自身で実現した深さ全体を反映していないということです：





したがって、Java、C＃、C ++などの通常のOOPプログラミング言語では、 継承という用語が使用されます。



JavaScriptでもほぼ同じものを使用しますが、少し広くなっています： legacyはlegacyです。



そして以来 ロシア語ではこれらの概念にほとんど違いはありません。したがって、なぜこれが必要なのかを理解したFuckUp'ovの集団です。



そして、私たちはレガシーコードからどこにも行かないからです 。



UPD 2 ： レガシーコードに関する記事からの抜粋>> 最新の解釈 。



...他の人から継承されたソースコードとソフトウェアの古いバージョンから継承されたソースコード...



UPD 3 ：カットの下では、継承が不可避的にレガシーを伴うという事実について話している。 まったく逆に、ネイティブスピーカーの用語によると、レガシーは継承以上のものです。



UPD 1：コメントは、部分的にはセピル・ワーフ仮説に関するものである可能性があることを示唆しています。 k12thに感謝します 。 建設的な批判をお寄せいただきありがとうございます。





Node.JS REPL> console.log（util.inherits.toString（））のコードを次に示します。 
function (ctor, superCtor) { ctor.super_ = superCtor; ctor.prototype = Object.create(superCtor.prototype, { constructor: { value: ctor, enumerable: false, writable: true, configurable: true } }); }


（もし興味があるなら、私はこのツールに目を通し、著者であるため、慎重に使用してください）





一般的に使用される通常のコードは次のとおりです。 

 function inherit(Child, Parent) { var BlankClass = function () {}; BlankClass.prototype = Parent.prototype; Child.prototype = new BlankClass(); Child.prototype.constructor = Child; Child.prototype.superclass = Parent; };




同じコードですが、javascript.ruから、

同じコードですが、javascript.ruから 
 function extend(Child, Parent) { var F = function() { }; F.prototype = Parent.prototype; Child.prototype = new F(); Child.prototype.constructor = Child; Child.superclass = Parent.prototype; };




javascript.ru/tutorial/object/inheritance



継承という用語が使用されていることに注意してください！



はい、そして、ここで、おそらく位置を明確にすることが重要です。 私は両方のアプローチのために、そのようなアプローチのためです。 しかし、私たち全員と同じように、私は広い意味でレガシーコードに反対しています。 しかし、それを回避することはできません。



その結果、通常これを行います： 



 var SomeChild = function () {}; var SomeParent = function () {}; inherit (SomeChild, SomeParent); SomeChild.prototype.overload_something = 'something_we_need_to_FuckUp';




その結果、実際には、「メソッドのオーバーロードによる継承」が実装されます。



誰もがそれに慣れているので、ここには問題がないようです。 これは「標準」実装であり、それから「どこにも」ありません。 これは、継承パラダイムに基づいています。



しかし、レガシーはそれと何の関係があるのでしょうか？



誰が言っても、この場合、 見解は常に親の側からであるという事実にもかかわらず、私は信じています。 再定義されたコードを理解するには、親が持っているメソッド、およびその親を調べ、そこにブランチがあるかどうかなどを調べる必要があります 。 それは常にそうだったようであり、誰もがそうだと仮定する必要があります。 これが、アーキテクチャと設計のすべてです。



これがマントラです。



そして、それについてはすべてが書かれているようで、これはすべての初心者に説明されています。



しかし、これは十分ではありません：



>>遺産に関連するレガシーは、より広い範囲またはより深い範囲になります。 継承が1つの世代から別の世代への贈り物を指す場合、レガシーは3世代または4世代を指します。 >>



つまり、ここでは、 プロトタイプチェーンが存在することを誰にも知らせません。



しかし、それをどのように使用し、なぜすべてが「そう」なのかは、初心者でも完全には明らかではないかもしれません。



したがって、レガシーと継承には違いがあることに注意してください。 そして、ネイティブスピーカーにとっては、ネイティブスピーカーではなく、私たちにとってよりも明白です。 なんらかの理由で、新参者はしばしばそれがほぼそこにあると考えます。



そして最後に、最も重要なことは、私の意見では、UPD 3で書かれていないことです：

レガシーという用語には、彼らにとっても私たちにとっても継承という用語が含まれます。 違いはそれほど前に私に明らかになりました。 そして、次に.prototypeを書くとき、このアプローチは必然的にレガシーの存在から来ることを覚えています。 したがって、私はそれなしでできるかどうかを7回考えます。 多分、他の言語ツールでこれらの数行のテキストを書くのに十分でしょう。 そして、それをすべて同じように使用しなければならない場合、次の子のコードを「スロー」すると、親の場合はレガシーであることを覚えています。


More articles:


All Articles