2010-11-14 3 views
1

Apparemment, il est un idiome en JavaScript pour la mise en œuvre de cette façon des méthodes d'instance à base de classe:function MyClass() {...}; MyClass.prototype = MyClass; - considéré comme nuisible?

function MyClass(){...} 
MyClass.prototype.methodA = function(){...} 
MyClass.prototype.methodB = function(){...} 
... 

Pourquoi ne sont pas les personnes qui utilisent cette forme moins bavard à la place:

function MyClass(){...} 
MyClass.prototype = MyClass; 
MyClass.methodA = function(){...} 
MyClass.methodB = function(){...} 

Il ne fonctionne évidemment pas si MyClass doit hériter d'une classe de base (dans ce cas, il faut généralement définir le prototype sur une nouvelle instance de la classe de base). Cependant, les hierachies d'héritage profond deviennent rares ces jours-ci (grâce au typage de canard et aux mixins entre autres).

Ai-je raté quelque chose? Est-ce que MyClass.prototype = MyClass rend le .constuctor plus en désordre qu'il ne l'est déjà?

Est-ce qu'il interfère de manière incorrecte avec typeof, ou instanceof, ou même getPrototypeOf()?

Devrait-il être promu ou considéré comme nuisible?

Répondre

1

Je pense que cela ne sert à rien, et cela vous expose à des problèmes potentiels si l'une de vos méthodes a un nom qui obscurcit une méthode native de Function.prototype.

Vous pouvez toujours initialiser le prototype comme ceci:

function MyConstructor() { ... } 

MyConstructor.prototype = { 
    myMethod: function() { ... }, 
    whatever: null 
}; 

modifier — si vous ne voulez pas créer des constantes d'objet (et je dois dire que si vous allez à coder en Javascript beaucoup, je suggère que vous essayez de vous habituer à eux), vous pouvez simplement faire ceci:

MyConstructor.prototype = {}; 
MyConstructor.prototype.myMethod = function() { ... }; 

Je n'aime pas faire beaucoup dactylographie, personnellement. Peut-être parce qu'il y a une forme encore moins verbeuse?

+0

Oui, c'est ce que j'avais l'habitude de faire. Cependant, l'indentation de niveau ajoutée, le "," que j'ai un peu gâché et le fait que je mélange parfois des définitions de fonctions avec des annotations de programmation méta ... m'ont rendu inconfortable avec ce style (je suis revenu à l'idiome .prototype classique, Je trouve une nouvelle solution) – JeanHuguesRobert

+0

BTW: Je ne comprends pas le "problème potentiel" que vous mentionnez, pourriez-vous élaborer sur ce point? Merci. – JeanHuguesRobert

+0

La classe Function dans Javascript a un tas de méthodes sur son propre objet prototype. Si vous ajoutez des méthodes etc. à votre objet fonction, vous ne pourrez pas utiliser ceux de cette instance. En d'autres termes, si vous ajoutez une méthode "call" à votre prototype, rien ne sera capable de faire MyConstructor.call (...) 'et d'obtenir le résultat attendu. – Pointy

2

MyClass.prototype = { 
    methodA: function(){}, 
    methodB: function(){} 
}; 

Cela devient plus propre plus des méthodes que vous avez, d'autres que cela, vous êtes juste remplaçant le prototype par défaut et tout ce qui était sur elle.

+0

Le prototype par défaut est {} Je pense, peut-être avec une propriété .constructor non énumérable pointant sur MyClass (I pas 100% de celui-là, je ne l'utilise jamais). Pas une grande perte jusqu'ici, à moins qu'il y ait une utilisation pour cela que j'ignore, des suggestions? – JeanHuguesRobert

+0

En outre, JavaScript a pour ainsi dire des "classes ouvertes", c'est-à-dire qu'on peut ajouter une méthode à tout moment, vous n'êtes pas obligé de les configurer tous en même temps ou à partir d'un fichier source unique. – JeanHuguesRobert

+0

La forme "encore moins verbeuse" est-elle moins verbeuse? Si j'ajoute les espaces d'identification et le séparateur, plus le}; Terminator ... Et lors de la navigation de gros fichiers, je me perds facilement, ne pas être rappelé quel est le cours pour lequel je définis une méthode. La lisibilité nécessite un certain niveau de redondance, où la verbosité implique une diminution du rapport signal/bruit. – JeanHuguesRobert

Questions connexes