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 2: strong> p> suis-je correct en supposant que
5 Réponses :
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. P>
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". P>
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 () code> pour créer une nouvelle instance de Ceci code>: 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 .
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"
En mots simples La différence est dans dans le second première méthode est bon d'ajouter de nombreuses fonctions que vous voulez La deuxième méthode est bonne si votre application s'oppose à des objets personne.pototype.sayname code> Tout ce que vous faites est d'ajouter une fonction au prototype code>. Il suffit d'ajouter de nouvelles fonctionnalités. p>
personne.Prototype = {} code> Vous faites un nouvel objet entier et assignez-le au prototype code>. Vous créez donc un nouvel objet ou écrasez le prototype code> avec un nouvel objet. p>
Fonctions mathématiques Code>) parmi elles. P>
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éthodeSayName 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); } });
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 Code>.
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;
};
Voir aussi Quelle est la différence entre ces prototypes de déclaration?