Héritage JavaScript du point de vue d'un nerd ennuyé: Constructors Factory

C'est l'histoire d'une pièce très spéciale de JavaScript, le langage artificiel le plus utilisé au monde aujourd'hui (2019).

L'article présente une sorte de vision philosophique de l'héritage en JavaScript, et j'ose seulement espérer qu'il est basé sur la source de connaissances la plus impressionnante: la vie elle-même dans toutes ses manifestations. Je ne sais pas si cela a été une inspiration lors de la création de la conception de la chaîne prototype en JavaScript.

Mais si c'est le cas, alors il est si important et puissant que lorsque je commence à y penser, il devient parfois même difficile de respirer ...

(tous les liens sont soulignés )

---

Je suis également sûr qu’aucun d’entre nous ne doutera que Brendan Ike (Eich) - l’auteur du langage de programmation JavaScript - est un génie exceptionnel! Et pas seulement parce qu'il répète souvent:

Pariez toujours sur JavaScript!

Commençons! Et notre premier point de départ sera l'Imagination, dans laquelle nous désactiverons d'abord tous les préjugés, omissions et autres effets secondaires.

Nous retournons vers le futur , l'ère précédant la création de l'Internet moderne au début des années 1990.

Depuis l'époque des premiers pirates qui ont inventé tout ce que nous ( les employés informatiques ) utilisons maintenant, nous sommes passés à un croquis impressionnant: à propos de la guerre entre les navigateurs Netstcape Navigator 2 et Internet Explorer 3. Java vient de sortir, et presque tout de l'Internet moderne n'a pas encore été inventé ou pas pré-ouvert. Il est possible que, comme moi, dans ce «bon vieux temps», vous étiez jeune et que vous vous souveniez de ce merveilleux sentiment d'implication dans toute la splendeur qui se crée sous vos yeux.

Donc, vous avez un PC très puissant sur le plus moderne Intell Pentium 200 MMX avec 32 Mo de RAM, Windows 3.11 ou même Windows 95 et vous envisagez l'avenir avec espoir! Et, bien sûr, les deux navigateurs sont également installés. Vous avez un accès commuté , à travers lequel vous vous connectez au réseau pour de nouvelles ordures, aussi, pour étudier ou simplement discuter, discuter. Bien que vous ne puissiez toujours pas discuter directement dans le navigateur, vous utilisez probablement des systèmes de livraison de messages différés, quelque chose comme EMail ou peut-être UseNet , ou, très probablement, vous avez déjà maîtrisé la livraison instantanée via IRC .

Quelques années s'écoulent et TOUT change littéralement ... Soudain, vous regardez l'animation de flocons de neige sur les pages Web pour vous féliciter pour le Nouvel An et Noël. Bien sûr, vous êtes intéressé par la façon dont cela se fait, et vous découvrez un nouveau langage - JavaScript. Puisque le HTML n'est pas nouveau pour vous, vous commencez à apprendre ce techno-métier séduisant. Bientôt, vous découvrez CSS et il s'avère que c'est également important, car tout est maintenant fait à partir d'une combinaison de ces trois: HTML, JavaSript et CSS. Ouah.

À peu près à la même époque, vous remarquerez peut-être quelques grandes choses dans Windows lui-même, CScript et HTA y sont apparus, et même alors, il est devenu possible de créer des applications de bureau à part entière directement sur JS (et cela fonctionne toujours).

Et vous avez donc commencé à créer votre premier serveur Web, peut-être en Perl ou en C ~ C ++ . Peut-être même que vous avez commencé à utiliser des systèmes d' exploitation de type Unix et à le faire sur bash . Et tout cela "spin-spinning" grâce à la Common Gateway Interface (ne le confondez pas avec cet autre CGI ). PHP n'existe presque toujours pas, mais vous l'aimerez peut-être bientôt.

Ère 200x. Vous faites maintenant ASP en JScript . Ceci est très similaire au JavaScript qui fonctionne à l'intérieur de vos pages Web. C'est trop cool! Vous envisagez de créer votre propre moteur de modèle , une sorte de parodie de XML . Et soudain, quelqu'un appelle AJAX toutes ces façons amusantes de charger dynamiquement du contenu que vous utilisez depuis plusieurs années. Et tous pensent maintenant qu'il n'y a que XMLHTTPRequest , mais vous vous souvenez que les données peuvent être transférées vers BMP , IFrame ou même en insérant la balise <script> . Et puis quelqu'un parle soudainement avec enthousiasme de JSON et de son utilité, lorsque vous avez conduit des données pendant une éternité avec quelque chose comme ceci:

document.write("<" + "script src=" + path + ">"); 

Ce n'est pas grave maintenant , mais vous pouvez toujours vous rappeler comment ...

Lorsque vous reprenez vos esprits, de temps en temps, vous commencez à vous retrouver à fouiner avec Rhino ou Nashorn pour tenter de satisfaire les souhaits des clients Java en utilisant Alfresco ou Asterisk . Et vous avez déjà entendu parler de l'avènement imminent de JavaScript dans le monde des micropuces, et vous êtes très inspiré par cette nouvelle. Et bien sûr, vous avez maintenant jQuery et Backbone .

En observant les chutes de neige de l'année 2010 à venir, vous savez déjà que dans votre monde toutes les règles du jeu vont bientôt changer, car «Player No. 1» est entré dans le champ: Node.js. Et les 10 prochaines années, vous passerez avec ce nouveau jouet, et même maintenant, en 2019, vous ne pouvez toujours pas en avoir assez de la fraîcheur.

En général, vous êtes satisfait de tout, tout vous convient, tous ces jouets et jeux en eux constituent une grande partie de vos intérêts de vie.

Mais il y a une petite question que vous vous posez jour après jour, nuit après nuit depuis deux décennies maintenant:

Si vous deviez le faire, comment expliqueriez-vous Empathy en utilisant JavaScript?

Vous savez que l'un des sujets les plus compliqués de JavaScript est l' héritage de prototypes et la chaîne de prototypes . Et vous aimez ce sujet, vous pouvez expliquer comment tout cela fonctionne et fonctionne, tout simplement parce que vous l'avez appris presque dès le début, avant même la naissance de la première version de la norme , et où, comme vous vous en souvenez, il y en a 4,2 .1 Objets :

ECMAScript prend en charge l'héritage basé sur un prototype. Chaque constructeur a un prototype associé, et chaque objet créé par ce constructeur a une référence implicite au prototype (appelé prototype de l'objet) associé à son constructeur. En outre, un prototype peut avoir une référence implicite non nulle à son prototype, etc. c'est ce qu'on appelle la chaîne prototype .

Chaque objet est créé avec une référence implicite au prototype. C'est ce qu'on appelle la chaîne d'héritage du prototype, que vous pouvez continuer aussi longtemps que vous le souhaitez.

Wow ... Et si tout à coup, comme moi, vous pensez peut-être que c'est l'une des plus grandes inventions de la science informatique , comment exprimeriez-vous l'effet que la lecture de cette déclaration a eu sur vous?

Revenons au début. Dans la cour 1995. Vous êtes Brendan Ike et vous devez inventer un nouveau langage de programmation. Peut-être que vous aimez Lisp ou Scheme , au moins certaines de leurs parties préférées. Et vous êtes confronté à la nécessité de résoudre le problème de l' héritage , car vous devez prétendre que le langage a une certaine implémentation de la POO . Réfléchissons : vous devez mélanger toutes les choses que vous aimez, peut-être aussi certaines choses que vous n'aimez pas, et le cocktail résultant devrait être assez bon pour que personne ne remarque un truc jusqu'à ce qu'il y ait un réel besoin de comprendre comment c'est disposé à l'intérieur.

Et maintenant, la question est: qu'arriverait-il à l'héritage?

Revenons un instant à la réalité. Que savons-nous tous de l'héritage? Quelques réponses évidentes à cette question:

1. La plupart des formes vivantes sont basées sur le génome . Il s'agit d'un tel référentiel d'informations sur les caractéristiques probables et le comportement présumé des êtres vivants. Lorsque vous êtes une créature vivante, vous portez une partie du génome en vous, vous pouvez le distribuer, mais vous l'avez reçu des générations précédentes.
2. Vous pouvez créer une créature vivante en utilisant deux techniques: mélanger (génomes) de deux ancêtres ou, éventuellement, utiliser le clonage monoïque de l' un d'eux. Bien sûr, aujourd'hui, nous sommes des technologies disponibles qui permettent de mélanger les génomes de plus d'une créature, mais cela est beaucoup moins évident et moins naturel.
3. Le facteur temps est important. S'il n'y a pas de propriété héritée, ou pas déjà, alors notre seule issue est de la créer à partir de zéro. En plus de cela, il y a aussi l'héritage, ce qui passe à l'être de ses ancêtres non pas à travers le génome, mais à travers les lois de la propriété, et cela peut aussi être significatif.

Pour en revenir au passé, et la bonne question que nous devons nous poser est maintenant: Et, en fait, l'héritage Que voulons-nous obtenir?

Eh bien, en tout cas, dans le processus de résolution du problème de l'héritage, nous devons au moins combler le fossé entre la programmation et la vie réelle, sinon, en général, nous n'aurons pas le droit de l'appeler héritage.

Finissons-en maintenant: nous sommes dans les années 1995, nous avons le PC le plus puissant avec seulement 32 mégaoctets de RAM, et nous essayons de créer un langage interprété, nous devons donc prendre grand soin de cette mémoire. Chaque élément de données, en particulier les objets String , consomme beaucoup de mémoire, et nous devrions être en mesure de déclarer cet élément une seule fois, et dans la mesure du possible à l'avenir, n'utilisez que des pointeurs vers la zone de mémoire occupée par cet élément. Nous résumons: une question très difficile.

Il y a une opinion populaire: " JavaScript est créé à partir d'objets ." En utilisant cette trivialité, nous pouvons très facilement répondre à la question « de quoi » hériter et « quoi »: d'Objets en Objets. Pour des raisons d'économie de mémoire, il s'avère que toutes les données doivent être stockées dans ces objets, et tous ces liens vers les données doivent également être stockés dans les propriétés héritées de ces objets. Peut-être que maintenant, il est clair pourquoi en 1995 nous avions vraiment besoin de créer un design basé sur une chaîne de prototype: il économise la mémoire le plus longtemps possible! Et en général, je pense que cela peut encore être un aspect très important.

Sur la base du design indiqué et de l'avis « tout est un objet », nous pouvons essayer de cloner quelque chose comme ça. Mais qu'est-ce que le clonage ici maintenant? Je pense qu'en suivant les exigences de nos exigences, nous pouvons supposer quelque chose comme Structural ou Surface Copy , quelque chose de similaire aux prédécesseurs de Object.assign moderne.
Implémentons une simple copie structurelle en 1995 en utilisant for (var i in) {} , car la norme le permettait déjà :

 // back in 1995 cloning // it is not deep clone, // though we might not need deep at all var cloneProps = function (clonedObject, destinationObject) { for (var key in clonedObject) { destinationObject[key] = clonedObject[key]; } }; 

Comme vous pouvez le voir, cette approche "fonctionne" toujours, bien qu'en général, bien sûr, je recommanderais de regarder le module approfondi pour une compréhension plus détaillée de la façon de faire du clonage en JavaScript, mais pour les besoins de l'article, une application cohérente nous convient tout à fait. décrit par cloneProps , car nous pourrions bien l'utiliser dans ces temps anciens:

• clonage d'objets à l'aide du constructeur: à l'aide du constructeur, créez au moins deux clones différents
  
  

   // cloneProps is described above var SomeConstructor = function (clonedObject) { cloneProps(clonedObject, this); }; var someExistingObjectToClone = { foo : 'bar' }; var clone1 = new SomeConstructor(someExistingObjectToClone); var clone2 = new SomeConstructor(someExistingObjectToClone); // clone1.foo == clone2.foo 

• clonage d'un constructeur à partir d'un constructeur: nous implémentons l'utilisation du comportement d'un constructeur à partir d'un autre constructeur
  
  

   var SomeConstructor = function () { this.a = 'cloned'; }; var AnotherConstructor = function () { // Function.prototype.call // was already invented in 1st ECMA-262 SomeConstructor.call(this); }; 

• clonage d'un constructeur à l'aide d'un objet: nous utiliserons le même objet pour implémenter le clonage dans au moins deux constructeurs
  
  

   var existentObject = { foo : 'bar' }; var SomeConstructor = function () { cloneProps(foo, this); }; var OtherConstructor = function () { cloneProps(foo, this); }; 

• clonage d'un objet à partir d'un autre objet: utilisez un objet pour créer plusieurs de ses clones . Il n'y a rien à décrire ici, prenez-le comme nos cloneProps du premier exemple ci-dessus.

Avec le clonage, en général, tout est simple, comme on le voit, tout est clair et en général, mais ...

Est-il si facile pour nous de faire l'héritage des entités, en utilisant une combinaison de leurs prédécesseurs?

• Héritage d'un objet à l'aide du constructeur: c'est le but même des concepteurs, nous allons simplement montrer comment il a été initialement conçu .
  
  

   var existentObject = { foo : 'bar' }; var SomeConstructor = function () {}; SomeConstructor.prototype = existentObject; var inheritedObject = new SomeConstructor(); // we have no instanceof yet in ECMA 262 of 1995 // therefore we are unable to rely on this window.alert(inheritedObject.foo); // bar 

• Héritage du constructeur d'un autre constructeur: sans aucun doute, le premier qui a remarqué que c'était un génie exceptionnel. Dans l'ensemble, c'est un autre exemple classique de partout .
  
  

   var FirstConstructor = function () { this.foo = 'bar'; }; var InheritedConstructor = function () { FirstConstructor.call(this); }; InheritedConstructor.prototype = { bar : 'foo' }; InheritedConstructor.prototype.constructor = FirstConstructor; var inherited = new InheritedConstructor(); // { foo : 'bar', bar : 'foo' } 

  
  il serait possible de dire quelque chose de sophistiqué, mais pourquoi
  
• Héritage du constructeur de l'objet: encore une fois, nous utilisons simplement .prototype = object chaque fois que nous en avons besoin, il n'y a rien à décrire, nous devons toujours assigner Constructor.prototype car il est censé y placer l'objet, et par un lien implicite nous obtenons toutes ses propriétés .
• Hériter d'un objet d'un objet: la même chose. Nous plaçons simplement le premier objet dans Constructor.prototype et dès que nous disons nouveau constructeur, nous créerons une copie héritée dans laquelle il y aura des références implicites aux propriétés de notre premier objet.

Et bien sûr, dans toutes ces situations avec héritage, nous aurons l'occasion de vérifier en utilisant instanceof à partir de quel constructeur nous avons créé les objets, bien que, bien sûr, il convient de noter que instanceof lui-même est apparu dans les normes près de quatre ans plus tard.

Certes, il restait un si petit détail du paragraphe 4.2.1:
être en mesure de le faire aussi longtemps que nécessaire, comme il est dit:

et ainsi de suite

Eh bien, essayons de rendre l'héritage vraiment sans fin , en utilisant la technologie de 1995 .

En fait, imaginons que nous avons deux Entités, et non des Constructeurs, mais des objets simples. Et nous voulions hériter l'un de l'autre, et puis peut-être de l'autre, et de l'autre, et ainsi de suite ...

Mais comment?

Jetez un œil un peu plus loin, plus profondément.
Ici encore, la bonne réponse est: l' héritage de ce que nous devons créer?

Après tout, nous n'avons pas besoin de ces entités par nous-mêmes. Nous avons besoin de leurs propriétés: données associées consommant de la mémoire; et aussi, nous avons probablement besoin d'un certain comportement: des méthodes utilisant ces données. Et ce sera tout aussi honnête , si nous avons la possibilité de vérifier où et où nous avons hérité et en utilisant quoi. En général, ce serait tout aussi cool si nous pouvions reproduire la conception inhérente des modèles d'héritage à l'avenir, ce qui implique que si nous héritons l'un de l'autre plusieurs fois, nous obtiendrons toujours le même résultat, selon ce que nous avons écrit (contrat) . Bien que ce soit encore, il peut être tout aussi utile pour nous de fixer en quelque sorte le moment de la création, car nos entités "précédentes" peuvent changer avec le temps, et les "héritiers", en leur donnant du respect en cela, changent toujours avec eux pourrait bien ne pas vouloir.

Et, puisque tout notre code est une combinaison de données et de comportement, est-il généralement normal d'utiliser la même méthode - combinant données et présentation - lors de la conception d'un système d'héritage?

Quant à moi, tout cela ressemble à ce que nous voyons en observant la vie sous toutes ses formes incroyables. Du premier unicellulaire au multicellulaire et à leurs descendants, et plus loin aux animaux, aux gens, à l'humanisme et aux tribus, aux civilisations, à l'intellect et à ses formes artificielles, et plus loin à l'espace, à la galaxie, aux étoiles! et:

"... Tout ce que nous devons faire, c'est nous assurer de continuer à parler ..."

(tout ce que nous devons faire est de continuer la communication)

Incroyable dans sa prévenance, une citation de Stephen Hawking , par la suite popularisée dans ce chef-d'œuvre de Pind Floyd .

Les langages de programmation basés sur le passage de messages et un concept basé sur Flow implémenté via une API interne robuste vous permettent de passer de données simples à des abstractions, des descriptions et tout le reste. Je pense que c'est de l'Art pur, et comment cela fonctionne en particulier dans les structures JavaScript profondément cachées à travers des relations implicites entre les données dans les chaînes de prototypes.

Imaginez à nouveau deux ancêtres, ils communiquent et à un moment leurs émotions et leurs sentiments créent un enfant. L'enfant grandit, rencontre un autre enfant, ils communiquent et le prochain descendant apparaît, et ainsi de suite ... Et nous avons toujours besoin de deux parents, sinon ce n'est pas naturel, ce sera déjà du génie génétique. Deux, ni plus ni moins. Un descendant reçoit la même chose que son héritage, c'est donc simple et compréhensible.

Je comprends que cela puisse sembler étrange, mais oui, nous avons tout ce dont nous avons besoin pour créer ce modèle d'héritage en 1995. Et la base de tout cela est précisément 4.2.1 Objets , référencement implicite via prototype.

Et c'est exactement comme ça, en combinant ParentObject avec ParentConstructor en spécifiant .prototype puis Constructor va probablement nous créer un ChildObject , bien sûr, si nous disons le mot magique " nouveau ":

 var ParentObject = { foo : 'bar' }; var ParentConstructor = function () {}; ParentConstructor.prototype = ParentObject; var ChildObject = new ParentConstructor(); // starting from 1995 and then ECMA 262 // we are able to say new // each time we need a ChildObject 

Nous pouvons discerner ici nos deux ancêtres. Au moment où nous avons dit le mot magique " nouveau ", nous leur avons demandé de discuter. S'ils ne veulent pas communiquer, Life s'arrêtera, le processus tombera avec une erreur et le compilateur (interprète) nous en parlera.

Bien sûr, oui, mais nous avons demandé l’ arbre d’héritage ou l’avons laissé être beaucoup plus simple, du moins pour l’arbre généalogique . Et la réponse est toujours la même ... notre objet enfant grandit, et il devient un objet parent , puis il rencontre un nouvel objet constructeur et dès que nous disons le mot convoité " nouveau " - magie:

 // this Assignment is just to show it grew up var ChildObjectGrownToParent = ChildObject; var AnotherConstructor = function () {}; AnotherConstructor.prototype = ChildObjectGrownToParent; var SequentialChildObject = new AnotherConstructor(); // checking Life Cycle ;^) console.log(ChildObject instanceof ParentConstructor); // true console.log(SequentialChildObject instanceof ParentConstructor); // true console.log(SequentialChildObject instanceof AnotherConstructor); // true 

Et nous pouvons continuer à le faire à l'infini. Et je crois peut-être vraiment que c'était l'idée principale lors du développement de la conception de la chaîne de prototypes, car comme nous le savons tous, cette approche crée des problèmes très soignés mais non moins désagréables ...

1: Communauté ... Comme vous pouvez facilement le vérifier par vous-même, spécifier dans .prototype ParentConstructor ' a ou AnotherConstructor' a est un contrat social très sérieux et strict dans notre tribu. Il crée une référence aux propriétés ParentObject ( .foo ) pour les héritiers: ChildObject et SequentialChildObject . Et si nous nous débarrassons de cette indication, ces liens disparaîtront. Si nous inventons et réaffectons cette référence à un autre objet, nos héritiers hériteront instantanément d'autres propriétés. Par conséquent, en combinant les ancêtres à travers .prototype , nous pourrions probablement dire que nous créons une sorte de cellule de la société , parce que ces «ancêtres» peuvent reproduire de nombreux descendants identiques chaque fois que nous leur en parlons en utilisant new . Et ainsi, ayant détruit la "famille", nous ruinons les qualités héréditaires de ses descendants, un tel drame; ^)

Peut-être que tout cela parle d' Héritage dans notre code, nous devons nous en occuper lorsque nous allons créer un code sûr et pris en charge ! Bien sûr, aucun SOLID , principe de Liskov et conception par contrat et GRASP n'ont été discutés en 1995, mais il est évident que ces méthodologies n'ont pas été créées «à partir de zéro», tout a commencé bien plus tôt.

2: Famille ... Nous pouvons facilement vérifier que notre ParentObject peut être très frivole avec d'autres Constructos. Ce n'est pas juste, mais nous pouvons utiliser autant de constructeurs que nous le souhaitons dans l'héritage de notre ParentObject et ainsi créer autant de familles que nous le souhaitons. D'un autre côté, chaque constructeur est très étroitement associé à ParentObject à travers la tâche .prototype, et si nous ne voulons pas nuire à nos héritiers, nous devons maintenir cette connexion aussi longtemps que possible. Nous pourrions l'appeler l'art de la tragédie dans l'histoire de notre tribu. Bien que, bien sûr, cela nous protège de l'amnésie - l'oubli de ce dont nous avons hérité et de qui, et pourquoi nos héritiers obtiennent un tel héritage . Et, en faisant l'éloge du grand Mnemosyne !, Nous pouvons vraiment facilement tester notre arbre de chaîne de prototype et trouver des artefacts de ce que nous avons fait de mal.

3: Vieillesse ... Notre ParentObject et Constructor sont certainement susceptibles d'être endommagés pendant le cycle de vie de notre programme. Nous pouvons essayer de nous en occuper, mais personne n'est à l'abri des erreurs. Et tous ces changements peuvent nuire aux héritiers. Nous devons prendre soin des fuites de mémoire . Bien sûr, nous pouvons très bien détruire les parties inutiles du code lors de l'exécution et ainsi libérer de la mémoire qui n'est plus utilisée dans notre cycle de vie . De plus, nous devons nous débarrasser de toutes les possibilités de créer des Paradoxes Temporaires dans les chaînes de prototypes, car en fait il est assez simple d'hériter l'Ancêtre de son propre Descendant. Mais cela peut déjà être très dangereux, car de telles techniques de flirt avec le passé du futur peuvent créer des tas entiers de Heisenbags difficiles à reproduire, surtout si nous essayons de mesurer quelque chose qui peut lui-même changer avec le temps.

Chronique des décisions

Que ce soit simple, évident et pas très utile, mais au lieu de penser à notre constructeur et ParentObject comme maman et papa, décrivons-les comme un œuf et ... du pollen . Ensuite, à l'avenir, lorsque nous créerons le Zygote en utilisant le mot précieux " nouveau ", cela ne fera plus de mal à notre imagination!

Dès que nous ferons cela, nous nous débarrasserons immédiatement des trois problèmes ci-dessus! Bien sûr, pour cela, nous avons besoin de pouvoir créer les zygotes eux-mêmes, ce qui signifie que nous avons besoin de la Factory of Designers. Et maintenant, appelez-le comme vous voulez, mères, pères, quelle différence cela fait-il, car en fin de compte, si nous voulons dire " nouveau ", nous devons créer une "toute nouvelle" cage de créateur de fleurs, y mettre du pollen, et seulement cela nous permettra pour faire pousser un nouveau «bon» Snowdrop dans le lointain et si enneigé 2020m:

 var Pollen = { season : 'Spring' }; // factory of constructors var FlowersFactory = function (proto) { var FlowerEggCell = function (sort) { this.sort = sort; }; FlowerEggCell.prototype = proto; return FlowerEggCell; }; var FlowerZygote = FlowersFactory(Pollen); var galanthus = new FlowerZygote('Galanthus'); 

(et oui, n'oubliez pas de vérifier la saison avec ce perce-neige, sinon les flocons de neige tomberaient ou tomberaient, et un perce-neige serait une fleur de printemps ...)

Bien sûr, la complexité cyclomatique des décisions que vous essayez de créer en utilisant cette approche sera assez comparable à l' énigme Einstein . Par conséquent, ici j'ai «concocté» une bibliothèque , cela peut aider à la création de chaînes de designers et à la mémorisation , (ndlr: bien, takoe, prenez une tarte sur une étagère, bla-bla-bla ) ...

Et bien que je ne puisse pas le prouver, cette approche a été utilisée avec succès de temps en temps pendant deux décennies maintenant, si vous devez être sûr à 146% que tout est normal avec l'héritage. Vous pouvez facilement constater par vous-même qu'il est élémentairement testé, reproduit et pris en charge (NDLR: oui, en ce moment, vous avez tout quitté et vous êtes allé vous en assurer ).

Bien sûr, ce n'est pas toute l'histoire, nous avons simplement déclaré le fait: JavaScript est suffisamment bien conçu pour décrire le graphique de généalogie directement via l'héritage. Bien sûr, ici, nous n'avons pas abordé sournoisement le sujet de la dégradation des classes , mais je suis sûr que vous pouvez vous-même facilement remplacer FlowerEggCell par FlowerEggCellClass dans FlowersFactory: l'essence restera la même si vous voulez vérifier vos fleurs par exemple, vous verrez qu'ils sont tous des descendants de FlowerEggCell auxquels vous vous référez via FlowerZygote . Et bien sûr, vous pouvez maintenant modifier les propriétés de FlowerZygote lui - même , car cela ne nuira pas à FlowersFactory lui - même , il restera capable de créer d'autres constructeurs FlowerEggCell ou FlowerEggCellClass à l'avenir selon la conception originale de " référence " que vous y avez mise .

J'espère que cet article a dissipé tous les doutes sur l'importance du mot .prototype la prochaine fois que vous verrez null this , . call (null , . apply (null . bind (null code style (. .: Sorrow , , , ).

!

!

V