Javascript 之中的 class/構造函數/工廠函數

時間 2019-11-16

標籤 javascript 之中 class 構造函數工廠欄目 JavaScript 简体版

原文原文鏈接

到了ES6時代，咱們建立對象的手段又增長了，在不一樣的場景下咱們能夠選擇不一樣的方法來創建。如今就主要有三種方法來構建對象，class關鍵字，構造函數，工廠函數。他們都是建立對象的手段，可是卻又有不一樣的地方，平時開發時，也須要針對這不一樣來選擇。javascript

首先咱們來看一下，這三種方法是怎樣的java

// class 關鍵字，ES6新特性
class ClassCar {
  drive () {
    console.log('Vroom!');
  }
}

const car1 = new ClassCar();
console.log(car1.drive());


// 構造函數
function ConstructorCar () {}

ConstructorCar.prototype.drive = function () {
  console.log('Vroom!');
};

const car2 = new ConstructorCar();
console.log(car2.drive());


// 工廠函數
const proto = {
  drive () {
    console.log('Vroom!');
  }
};

function factoryCar () {
  return Object.create(proto);
}

const car3 = factoryCar();
console.log(car3.drive());
複製代碼

這些方法都是基於原型的建立，並且都支持在構造時函數中私有變量的實現。換句話來講，這些函數擁有着大部分相同的特性，甚至在不少場景下，他們是等價的。程序員

在 Javascript 中，每個函數都能返回一個新的對象。當它不是構造函數或者類的時候，它就被稱做工廠函數。安全

ES6的類實際上是構造函數的語法糖（至少現階段是這樣實行的），因此接下來討論的全部內容都適用於構造函數的也適用於ES6類：bash

class Foo {}
console.log(typeof Foo); // function
複製代碼

構造函數和ES6類的好處

大部分的書會教你去用類和構造函數
‘this’ 是指向新的這個對象的。
一些人喜歡 new 關鍵字的可讀性
也許還會有一些很小的細節方面的差異，可是若是在開發過程當中沒有問題的話，也不用太擔憂。

構造函數和ES6類的壞處

1. 你須要 new 關鍵字

到了ES6，構造函數和類都須要帶 new 關鍵字。app

function Foo() {
  if (!(this instanceof Foo)) { return new Foo(); }
}
複製代碼

在ES6中，若是你嘗試調用類函數沒有 new 關鍵字就會拋出一個任務。若是你要個不用 new 關鍵字的話，就只能使用工廠函數把它包起來。函數

2. 實例化過程當中的細節暴露給了外界API

全部的調用都牢牢的關聯到了構造器的實現上，若是你須要本身在構造過程當中動一些手腳，那就是一個很是麻煩的事情了。oop

3. 構造器沒有遵照 Open / Closed 法則

由於new關鍵字的細節處理，構造器違反 Open / Closed 法則：API應該開放拓展，避免修改。post

我曾經質疑過，類和工廠函數是那麼的類似，把類函數升級爲一個工廠函數也不會有什麼影響，不過在JavaScript裏面，的確有影響。ui

若是你開始寫着構造函數或者類，可是寫着寫着，你發現須要工廠函數的靈活性，這個時候你不能簡單的就改改簡單改改函數一走了之。

不幸的是，你是個JavaScript程序員，構造器改形成工廠函數是一個大手術：

// 原來的實現：

// class Car {
// drive () {
// console.log('Vroom!');
// }
// }

// const AutoMaker = { Car };

// 工廠函數改變的實現：
const AutoMaker = {
  Car (bundle) {
    return Object.create(this.bundle[bundle]);
  },

  bundle: {
    premium: {
      drive () {
        console.log('Vrooom!');
      },
      getOptions: function () {
        return ['leather', 'wood', 'pearl'];
      }
    }
  }
};

// 指望中的用法是：
const newCar = AutoMaker.Car('premium');
newCar.drive(); // 'Vrooom!'

// 可是由於他是一個庫
// 許多地方依然這樣用:
const oldCar = new AutoMaker.Car();

// 如此就會致使:
// TypeError: Cannot read property 'undefined' of
// undefined at new AutoMaker.Car
複製代碼

在上面例子裏面，咱們從一個類開始，最後把它改爲來一個能夠根據特定的原型來建立對象的工廠函數，這樣的函數能夠普遍應用於接口抽象和特殊需求定製。

4. 使用構造器讓 `instanceof` 有可乘之機

構造函數和工廠函數的不一樣就是instanceof操做符，不少人使用instanceof來確保本身代碼的正確性。可是說實話，這是有很大問題的，建議避免instanceof的使用。

instanceof 會說謊。

// instanceof 是一個原型鏈檢查
// 不是一個類型檢查

// 這意味着這個檢查是取決於執行上下文的,
// 當原型被動態的從新關聯,
// 你就會獲得這樣使人費解的狀況

function foo() {}
const bar = { a: 'a'};

foo.prototype = bar;

// bar是一個foo的實例嗎，顯示不是
console.log(bar instanceof foo); // false

// 上面咱們看到了，他的確不是一個foo實例
// baz 顯然也不是一個foo的實例，對吧?
const baz = Object.create(bar);

// ...不對.
console.log(baz instanceof foo); // true. oops.
複製代碼

instanceof並不會像其餘強類型語言那樣作檢查，他只是檢查了原型鏈上的對象。

在一些執行上下文中，他就會失效，好比你改變了Constructor.prototype 的時候。

又好比你開始些的是一個構造函數或者類，以後你又將它拓展爲一個另外一個對象，就像上面改寫成工廠函數的狀況。這時候instanceof也會有問題。

總而言之，instanceof是另外一個構造函數和工廠函數呼喚的大改變。