Pourquoi l'attribution de méthodes prototypes à l'intérieur de la fonction constructeur est-elle généralement considérée comme une mauvaise pratique en JavaScript ?

Attribution de méthodes de prototype à l'intérieur du constructeur : inconvénients potentiels et problèmes de portée

Tout en hiérarchisant les préférences stylistiques, il est crucial de résoudre les inconvénients potentiels et les problèmes de portée associé à l'attribution de méthodes prototypes à l'intérieur de la fonction constructeur. Considérez les structures de code suivantes :

Structure 1 :

<code class="javascript">var Filter = function(category, value) {
  this.category = category;
  this.value = value;

  // product is a JSON object
  Filter.prototype.checkProduct = function(product) {
    // run some checks
    return is_match;
  }
};</code>

Structure 2 :

<code class="javascript">var Filter = function(category, value) {
  this.category = category;
  this.value = value;
};

Filter.prototype.checkProduct = function(product) {
  // run some checks
  return is_match;
}</code>

Inconvénients et problèmes de portée :

1. Assignations répétées de prototypes et création de fonctions :
Dans la structure 1, le prototype est réaffecté encore et encore à chaque création d'instance. Cela répète non seulement l'affectation, mais crée également un nouvel objet fonction pour chaque instance.

2. Problèmes de portée inattendus :
La structure 1 peut entraîner des problèmes de portée inattendus. Si une méthode prototype fait référence à une variable locale du constructeur, la première structure peut entraîner un comportement inattendu. Prenons l'exemple suivant :

<code class="javascript">var Counter = function(initialValue) {
  var value = initialValue;

  // product is a JSON object
  Counter.prototype.get = function() {
      return value++;
  }
};

var c1 = new Counter(0);
var c2 = new Counter(10);
console.log(c1.get());    // outputs 10, should output 0</code>

Dans ce cas, la méthode get créée pour chaque instance partage le même objet prototype. En conséquence, la variable de valeur est incrémentée et partagée entre les instances, ce qui entraîne une sortie incorrecte.

Autres considérations :

• La structure 1 empêche l'accès externe à le prototype via Filter.prototype.checkProduct.apply().
• En termes de performances, attribuer des méthodes directement à l'instance d'objet peut être plus efficace que d'utiliser le prototype.
• Attribuer des méthodes prototypes à l'intérieur du Le constructeur peut entraîner des erreurs de programmation, en particulier lors du référencement de variables locales.

Conclusion :

Bien que les préférences personnelles puissent varier, il est important d'être conscient du potentiel inconvénients et problèmes de portée associés à l’attribution de méthodes prototypes à l’intérieur de la fonction constructeur. Pour des raisons de fiabilité et de maintenabilité, la deuxième structure de code est généralement recommandée.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!