11
votes

Définition d'un prototype JavaScript

Quelles sont les différences fonctionnelles entre les deux prototypes JavaScript suivants et y a-t-il des avantages pour en choisir un sur l'autre?

Option 1: xxx

Option 2: xxx

suis-je correct en supposant que option 2 entraîne la corbeille de certaines fonctions qui sont implicitement liés au prototype?


5 Réponses :


2
votes

Le premier est bon pour une ou deux fonctions supplémentaires, mais la définition d'un prototype totalement nouveau avec de nombreuses fonctions serait très répétitif. D'autre part, ce dernier détruirait toutes les définitions existantes du prototype que vous avez mentionnées.

En pratique, j'ai utilisé le premier à définir des fonctions supplémentaires dans la matrice et les mathématiques, etc., des catégories similaires dans l'objectif-c. Ce dernier que j'utilise comme une "définition de classe".


3 commentaires

Je comprends que lorsque vous ajoutez une bibliothèque de code existante (comme maths), vous ne voudriez pas ou détruit complètement le prototype, mais lors de la création d'une nouvelle bibliothèque à partir de zéro, y a-t-il une raison pour laquelle je ne devrais pas détruire le prototype? En d'autres termes, lorsque je crée un nouveau prototype, a-t-il déjà des fonctions qui lui sont déjà associées ou est-ce juste un espace réservé vierge?


@Richardkeller Vous écraserez le prototype de la fonction avec celle de l'objet afin que vous ne puissiez pas utiliser nouveau this.constructor () pour créer une nouvelle instance de Ceci : phrogz.net/js/classes/oopinjs2.html


Vous êtes assez sûr avec de nouveaux prototypes. J'ai essayé d'expérimenter dans la console Google Chrome et je ne peux rien détruire d'importance. Voir cette Lien .



3
votes

Le second écrasera la personne.Prototype avec l'objet.

Méthode 1: P>

Object.toString=function(){
  return "Object to string";
}
var Person = function(){
};
Person.toString=function(){
  return "Person to string";
}
Person.prototype = {
  sayName:function(){}
}
console.log(Person.prototype.constructor.toString());// "Object to string"


0 commentaires

0
votes

En mots simples La différence est dans personne.pototype.sayname Tout ce que vous faites est d'ajouter une fonction au prototype . Il suffit d'ajouter de nouvelles fonctionnalités.

dans le second personne.Prototype = {} Vous faites un nouvel objet entier et assignez-le au prototype . Vous créez donc un nouvel objet ou écrasez le prototype avec un nouvel objet.

première méthode est bon d'ajouter de nombreuses fonctions que vous voulez à la demande . Vous pouvez les ajouter chacun à temps, alors je pense que c'est bon lorsque votre programme est simple et que vos objets d'application peuvent ne pas partager de nombreuses fonctions ou objets parmi eux.

La deuxième méthode est bonne si votre application s'oppose à des objets (ou groupe de fonctions comme @isaach dit dans Fonctions mathématiques ) parmi elles.


0 commentaires

6
votes

suis-je correct pour supposer que l'option 2 entraîne la prélèvement de certaines fonctions qui sont implicitement liées au prototype? P>

Oui, exactement. Bien que la seule propriété implicitement liée soit la propriété constructeur code>, que vous avez rarement besoin de besoin. P>

Quelles sont les différences fonctionnelles? P> BlockQuote>

L'option 1 vient d'étendre le prototype existant. S'il y a déjà Personne Code> Les instances héritantes à partir de l'objet prototype, elles pourront utiliser la méthode SayName code>. Avec l'option 2, le nouveau prototype ne sera utilisé que pour des objets instanciés après l'écrasement. P>

Y a-t-il des avantages pour en choisir un sur l'autre? p> BlockQuote>

Ceux-ci devraient être auto-expliquant maintenant. L'option 1 (s'étendant) est considérée comme plus propre et est indispensable si vous modifiez des prototypes étrangers / inconnus / natifs. Essayez d'éviter l'option 2. P>

Si vous aimez toujours la syntaxe littérale objet meilleure, vous devez envisager d'utiliser objet.Assign code> pour étendre le prototype existant: p>

Object.assign(Person.prototype, {
   sayName: function(name) {
      alert(name);
   }
});


2 commentaires

Pourquoi sur Terre devrait-il être considéré comme plus propre. Il semble que l'option 2 est la voie à suivre avec une ardoise propre pour ainsi dire.


@AlexMills: Parce que vous n'avez pas besoin de savoir quelles propriétés existent déjà sur le prototype que vous écrasiez autrement et ne les casserez pas (peu importe où le code est appelé). C'est plus simple, moins cumulée d'erreur et d'avant-la-compatible. Bien sûr, si vous créez un objet prototype à partir de zéro, vous pouvez également utiliser l'objet littéral, mais même la plupart des gens oublient la propriété Standard Constructor .



1
votes

Toutes les instances existantes du constructeur continueront de pointer sur l'ancien objet prototype. Toute nouvelle instances créée indiquera le nouvel objet prototype.


Les avantages de l'option 1 sur l'option 2 sont simplement que vous n'avez pas à rétablir la propriété du constructeur et que vous enregistrez un niveau d'indentation qui est énorme pour Moi. p>

Pour enregistrer la répétition, je viens d'affecter la propriété à une variable locale: p>

var method = Person.prototype;

method.getAge = function() {
    return this.age;
};

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


0 commentaires