為什麼在 JavaScript 中，在建構函式內分配原型方法通常被認為是不好的做法？

在構造函數內分配原型方法：潛在的缺點和範圍問題

在優先考慮風格偏好的同時，解決潛在的缺點和範圍問題至關重要與在建構函數內分配原型方法相關。考慮以下代碼結構：

結構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>

結構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>

缺點與範圍問題：

1。重複原型分配和函數創建：
在結構 1 中，每次創建實例時都會一遍又一遍地重新分配原型。這不僅會重複賦值，還會為每個實例建立一個新的函數物件。

2.意外的範圍問題：
結構 1 可能會導致意外的範圍問題。如果原型方法引用建構函數的局部變量，則第一個結構可能會導致意外行為。考慮以下範例：

<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>

在這種情況下，為每個實例建立的 get 方法共用相同的原型物件。因此，值變數會遞增並在實例之間共享，從而導致錯誤的輸出。

其他注意事項：

• 結構 1 阻止外部存取透過 Filter.prototype.checkProduct.apply() 取得原型。
• 從效能角度來說，直接為物件實例分配方法可能比使用原型更有效。
• 在建構子可能會導致程式錯誤，特別是在引用局部變數時。

結論：

雖然個人偏好可能有所不同，但重要的是要意識到潛在的可能性與在構造函數內分配原型方法相關的缺點和範圍問題。為了可靠性和可維護性，一般建議第二種程式碼結構。

以上是為什麼在 JavaScript 中，在建構函式內分配原型方法通常被認為是不好的做法？的詳細內容。更多資訊請關注PHP中文網其他相關文章！