Javascript 之中的 class/建構函式/工廠函式

Dominic_Ming發表於2017-12-20
JavaScript函式

到了ES6時代，我們建立物件的手段又增加了，在不同的場景下我們可以選擇不同的方法來建立。現在就主要有三種方法來構建物件，class關鍵字，建構函式，工廠函式。他們都是建立物件的手段，但是卻又有不同的地方，平時開發時，也需要針對這不同來選擇。

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

// 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類：

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

建構函式和ES6類的好處

  • 大部分的書會教你去用類和建構函式
  • ‘this’ 是指向新的這個物件的。
  • 一些人喜歡 new 關鍵字的可讀性
  • 也許還會有一些很小的細節方面的差別，但是如果在開發過程中沒有問題的話，也不用太擔心。

建構函式和ES6類的壞處

1. 你需要 new 關鍵字

到了ES6，建構函式和類都需要帶 new 關鍵字。

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

在ES6中，如果你嘗試呼叫類函式沒有 new 關鍵字就會丟擲一個任務。如果你要個不用 new 關鍵字的話，就只能使用工廠函式把它包起來。

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

所有的呼叫都緊緊的關聯到了構造器的實現上，如果你需要自己在構造過程中動一些手腳，那就是一個非常麻煩的事情了。

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

因為new關鍵字的細節處理，構造器違反 Open / Closed 法則：API應該開放擴充，避免修改。

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

如果你開始寫著建構函式或者類，但是寫著寫著，你發現需要工廠函式的靈活性，這個時候你不能簡單的就改改簡單改改函式一走了之。

不幸的是，你是個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是另一個建構函式和工廠函式呼喚的大改變。

用類的好處

  • 一個方便的，自包含的關鍵字
  • 一個唯一的權威性方法在JavaScript來實現類。
  • 對於其他有class的語言開發經驗的開發者有很好的體驗。

用類的壞處

構造器所有的壞處, 加上:

  • 使用 extends 關鍵字建立一個有問題的類，對於使用者是一個很大的誘惑。

類的層級繼承會造成很多有名的問題，包括 fragile base class（基礎類會因為繼承被破壞），gorilla banana problem（物件混雜著複雜的上下文環境），duplication by necessity（類在繼承多樣化時需要時時修改）等等。

雖然其他兩種方法也有可能讓你陷入這些問題，但是在使用 extend 關鍵字的時候，環境使然，就會把你引導上這條路。換句話說，他引導你向著一個不靈活的關係編寫程式碼，而不是更有複用性的程式碼。

使用工廠函式的好處

工廠函式比起類和建構函式都更加的靈活，也不會把人引向錯誤的道路。也不會讓你陷入深深的繼承鏈中。你可以使用很多手段來模擬繼承

1. 用任意的原型返回任意的物件

舉個例子，你可以通過同一個實現來建立不同的例項，一個媒體播放器可以針對不同的媒體格式來建立例項，使用不同的API，或者一個事件庫可以是針對DOM時間的或者ws事件。

工廠函式也可以通過執行上下文來例項化物件，可以從物件池中得到好處，也可以更加靈活的繼承模型。

2. 沒有複雜重構的擔憂

你永遠不會有把工廠函式轉換成建構函式這樣的需求，所以重構也沒必要。

3. 沒有 new

你不用new關鍵字來新建物件，自己可以掌握這個過程。

4. 標準的this 行為

this 就是你熟悉的哪個this，你可以用它來獲取父物件。舉個例子來說，在player.create() 中，this指向的是player，也可以通過call和apply來繫結其他this。

5. 沒有 instanceof 的煩惱

6. 有些人喜歡直接不帶new的寫法的可讀直觀性。

工廠函式的壞處

  • 並沒有自動的處理原型，工廠函式原型不會波及原型鏈。
  • this 並沒有自動指向工廠函式裡的新物件。
  • 也許還會有一些很小的細節方面的差別，但是如果在開發過程中沒有問題的話，也不用太擔心。

結論

在我看來，類也許是一個方便的關鍵字，但是也不能掩飾他會把毫無防備的使用者引向繼承深坑。另一個風險在於未來的你想要使用工廠函式的可能性，你要做非常大的改變。

如果你是在一個比較大的團隊協作裡面，如果要修改一個公共的API，你可能干擾到你並不能接觸到的程式碼，所以你不能對改裝函式的影響視而不見。

工廠模式很棒的一個地方在於，他不僅僅更加強大，更加靈活，也可以鼓勵整個隊伍來讓API更加簡單，安全，輕便。

翻譯自：medium.com/javascript-…

作者：Eric Elliott

翻譯：Dominic Ming

相關文章