JS的class、建構子、工廠函式使用方法

這次帶給大家JS的class、建構子、工廠函式使用方法，使用JSclass、建構子、工廠函式的注意事項有哪些，下面就是實戰案例，一起來看一下。

到了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更加簡單，安全，輕便。

相信看了本文案例你已經掌握了方法，更多精彩請關注php中文網其它相關文章！

推薦閱讀：

使用nodejs在微信中呼叫收貨地址

keep-alive在vue2中應該怎樣使用

以上是JS的class、建構子、工廠函式使用方法的詳細內容。更多資訊請關注PHP中文網其他相關文章！