應該在JavaScript中使用Class嗎？

看似無處不在的OOP

OOP 即面向對象編程（Object Oriented Programming）毫無疑問是軟件設計和發展中的一大進步。事實上，一些編程語言如 Java 、C++ 就是基於 OOP 的核心概念 class 開發出來。

在高校的 CS 相關專業中，無論教授什麼編程語言，OOP的學習是絕對不會被落下的。

同時，OOP在業界中也的確被大量使用，尤其是的後端服務領域、桌面軟件、移動APP開發等。

因此，OOP看起來在軟件行業無處不在，在這種有點教條主義的氛圍下，很多程序員甚至以爲 class 是編程固有的概念 —— 然而並不是。

OOP 只是一套幫助開發者設計和編寫軟件的方法論，但並不代表它能解決所有領域的問題，也不是能在所有編程語言的任何場景下都適用。我們應避免陷入這種教條主義。

JavaScript中使用Class的坑

ES6 之後，JavaScript 也引入了 class 關鍵字用於聲明一個類。但需要注意的是，這樣聲明出來的類其實在底層還是使用了 JavaScript 的函數和原型鏈（來模擬類的行爲）

看個例子：

class Person {
  constructor (name) {
    this.name = name
  }
  
  talk () {
    console.log(`${this.name} says hello`)
  }
}

上面的代碼在底層實現時，非常接近於

function Person (name) {
  this.name = name
}
Person.prototype.talk = function () {
  console.log(`${this.name} says hello`)
}

這邊可以注意到 talk 其實並不是一個Person類內部封裝的方法，而只是一個常規的JavaScript函數，賦值到了Person的原型上而已。因此，talk 函數裏的 this 對應的是調用時的上下文而不是定義時的上下文，這點跟 Java 和 C++ 的差別很大。

這種差異最明顯的影響是在別的對象試圖調用這個對象的talk時

const Grey = new Person('Grey')
const mockDomButton = {} // 模擬一個DOM上的按鈕對象
mockDomButton.onClick = Grey.talk; // 綁定點擊事件
mockDomButton.onClick() // 輸出的結果是 undefined says hello

上面這段模擬代碼輸出的結果並不是我們想要的。原因是 onClick 被調用時，其實是 talk 函數在執行，且talk 函數的this 指向的是 mockDomButton 而不是 Grey ，mockDomButton 並沒有 name 屬性於是輸出了 undefined says hello

這種“特殊”的表現讓很多 JavaScript 新手感到頭疼，尤其是那些從 Java 或者 C++ 背景過來的新手前端程序員。

解決這個問題的辦法當然是有的，先介紹兩個仍然使用 class 的方案

方案一：

使用函數的 bind 方法

bind()方法創建一個新的函數，在 bind()被調用時，這個新函數的 this被指定爲 bind()的第一個參數

修改 Person.js 文件如下

class Person {
  constructor (name) {
    this.name = name
    this.talk = this.talk.bind(this); // 在構造器裏顯式調用 bind 函數綁定 this
  }

  talk () {
    console.log(`${this.name} says hello`)
  }
}

再次運行上面的測試代碼，這次的輸出就是正確的了 —— Grey says hello

這種方案的缺點就是需要繁瑣地寫這種 bind 方法調用語句，當這個類的方法很多時，會顯得構造器非常臃腫，降低可讀性和編碼效率如

方案二：

使用類屬性+箭頭函數的方式來定義方法

即

class Person {
  constructor(name) {
    this.name = name
  }

  talk = () => {
    console.log(`${this.name} says hello`)
  }
}

這種語法是 ES2017 才引入的，它等效於

class Person {
  constructor(name) {
    this.name = name
    this.talk = () => {
      console.log(`${this.name} says hello`)
    }
  }
}

運行測試代碼，依然能成功輸出 Grey says hello

但是，這種方案也有缺點 —— 由於它等效於函數定義放在了構造器內，所以

一、這個方法不在原型鏈上，即 Person.prototype.talk 的值是undefined ，所以這個類的子類並不能使用 super.talk() 調用到父類這個方法，所以下面這段代碼會報錯

class Student extends Person {
  talk = () => {
    super.talk(); // 報錯
    console.log("student talk hi");
  }
}

const student = new Student('Tom');
student.talk();

二、每次創建一個 Person 實例都會創建一個 talk 函數，造成性能浪費（僅僅是用來與方案一對比）

const Grey = new Person('Grey')
const Tom = new Person('Tom')
console.log(Grey.talk === Tom.talk); //  輸出 false

在 JavaScript 中使用類居然有上面這麼多坑，那何不試試其他方案？

首先，我們回到源頭想想什麼是類，我們想利用類達到什麼目的：

大多數時候，我們定義的類其實是創建對象的藍圖（模板） —— 我們先規劃好一個類的模樣，之後通過 new 的方式創建出許許多多的對象，每個對象都符合我們想要的格式（即屬性，方法）

在 JavaScript 中，我們還有其他方案可以達到這個目的

工廠函數（factory functions）

const PersonFactory = (name) => {
  return {
    talk: () => {
      console.log(`${name} says Hello`)
    }
  }
}

PersonFactory 是個簡單的工廠函數，它返回一個對象，這個對象擁有一個 talk 方法

(p.s. 我更新了一下代碼，看起來可讀性更高一點，想看原版代碼的可以查看歷史記錄）

const Grey = PersonFactory('Grey'); // 使用工廠函數生成對象
const mockDomButton = {} // 模擬一個DOM上的按鈕對象
mockDomButton.onClick = Grey.talk; // 綁定點擊事件
mockDomButton.onClick() // 輸出的結果是 Grey says Hello

由於JavaScript的閉包特性，name已經被封裝在了函數裏，所以上面的測試代碼可以正常運作。而且更讚的是，這個方案中，name甚至自動成爲了私有的變量，不怕被更改（上面的那些 class 方案裏 name 都可以被公共訪問的）

而且相比之下，工廠函數的代碼更簡潔易讀，也不需要考慮 this 的繁瑣問題。

因此，如果只是爲了給對象創建繪製藍圖（模板），工廠函數是比類更合適的方案。

繼承

類的另一個特徵是繼承機制，子類可以繼承（分享）來自父類的屬性和方法。

如果僅僅是共享屬性和方法，使用組合（composition）也可以很容易實現

const Workable = {
  inOffice: true
}
const WorkablePersonFactory = (name) => (
  Object.assign(
    {},
    Workable,
    PersonFactory(name)
  )
)
// 或者
const WorkablePersonFactory = (name) => (
    {
     ... Workable,
     ...PersonFactory(name),
    }
)

上面的代碼意圖十分明顯，可讀性很高，這也是組合模式的一個優點。

當然，對於某些更復雜的類使用場景，工廠函數並不能替代類。

關注代碼表達性而不是死守教條主義

在 JavaScript 的現實場景中，尤其是前端代碼，我們很少真正用到類繼承，大多數時候，工廠函數就能完成我們的目標。

以React爲例，官方這幾年推崇 Hooks 的意圖也很明顯 —— 擺脫JavaScript class 帶來的複雜性，擁抱函數式風格。

由於 JavaScript 實現的特殊性，在 JavaScript 應用中使用 class 對於一些程序員來說有許多坑，於此同時，大多數場景下其他替代方案如工廠函數可能更契合JavaScript的特性，反而帶來更好的效果。

當然，並不是一杆子打死 JavaScript 的 class，在一些特別適合 OOP 的場景中，依然鼓勵使用 class 。

總之，不要被教條主義所束縛，牢記編寫程序最重要的兩點是：

真正將需求轉化成了代碼
寫出可讀的，容易維護的，方便理解的代碼

個人體驗

在我的工作負責的幾個項目中，其中一個Nodejs項目，我發現了大量的不必要的 class ，在constructor中充斥着大量的 bind 語句，而且這些 class 的方法之間並沒有太多關係，很多class也沒有內部狀態；更像是爲了聲明這些函數是屬於同一個模塊而已 —— 也就是說根本不必要以 class 的形式組織代碼。

於是，在日常任務完成之餘，我就花了點時間，把這些class方法全部重構成普通的 function，再利用 ES6 module 的形式重新組織這些代碼。現在這些代碼乾淨、清晰了很多。

（關於 Nodejs 的 module 以及如何在 Nodejs 中使用 ES6 module，歡迎閱讀我的另一篇文章）

FreewheelLee：[搬運] JavaScript 模塊化：CommonJS vs AMD vs ES6zhuanlan.zhihu.com

沒想到這篇文章有這麼高的閱讀量，以及部分爭議。統一回復一下吧。

本文的討論的場景主要是基於業務開發的上下文，不包括底層庫、工具庫開發等場景。

1. bind 以外的其他方案

感謝

@賀師俊

大佬的提醒

class fields或者autobind decorator都有很多問題，而且這兩者還不是最終標準，建議不要用

讀者們可以參考

2. 關於工廠函數的舉例

首先這個例子主要是針對這種場景 ——在 JavaScript 給創建某類對象定製一個標準，以便可以用這個模板創建許多對象

這個例子的確還不夠亮眼，那我再舉個更實際的例子吧

function httpClientFactory(baseUrl) {
  return {
    baseUrl: baseUrl,
    listUsers: () => {
      return axios.get(`${baseUrl}/users`)
    },
    getUser: (id) => {
      return axios.get(`${baseUrl}/users/${id}`)
    },
    createUser: (user) => {
      return axios.post(`${baseUrl}/users`, user);
    },
    listBooks: () => {
      return axios.get(`${baseUrl}/books`)
    },
    getBook: (bookName) => {
      return axios.get(`${baseUrl}/books/${bookName}`)
    },
    createBook: (book) => {
      return axios.post(`${baseUrl}/books`, book)
    }
  }
}

const httpClient = httpClientFactory("https://your-endpoints/api");
httpClient.getUser("123");
httpClient.getBook("JavaScript Is Interesting");
console.log("The httpClient's baseUrl is " + httpClient.baseUrl);

對比

class HttpClient {
  constructor(baseUrl) {
    this.baseUrl = baseUrl;
    this.listUsers = this.listUsers.bind(this);
    this.getUser = this.getUser.bind(this);
    this.createUser = this.createUser.bind(this);
    this.listBooks = this.listBooks.bind(this);
    this.getBook = this.listUsers.bind(this);
    this.createBook = this.createBook.bind(this);
  }

  listUsers() {
    return axios.get(`${this.baseUrl}/users`)
  }

  getUser(id) {
    return axios.get(`${this.baseUrl}/users/${id}`)
  }

  createUser(user) {
    return axios.post(`${this.baseUrl}/users`, user);
  }

  listBooks() {
    return axios.get(`${this.baseUrl}/books`)
  }

  getBook(bookName) {
    return axios.get(`${this.baseUrl}/books/${bookName}`)
  }

  createBook(book) {
    return axios.post(`${this.baseUrl}/books`, book)
  }
}

const httpClient = new HttpClient("https://your-endpoints/api");
httpClient.getUser("123");
httpClient.getBook("JavaScript Is Interesting");
console.log("The httpClient's baseUrl is " + httpClient.baseUrl);

感受一下代碼的整潔程度

（彩蛋：bind 語句複製粘貼導致的bug你們發現了嗎？）

3. 注意使用 class 的初衷

太多開發者一上來就寫個class的原因通常是因爲他/她是從OOP背景過來的 —— 在Java，你不能光禿禿地定義一個常量，一個函數或者一個表達式，你得先有個類，然後在類裏定義一個靜態不可變的屬性（public static final 三連）才能產生一個常量，類似的，也只能在類裏定義一個（靜態或者非靜態）的方法才能讓函數有容身之地（爲了防槓，我謹慎加一條 —— Java 8 的 functional interface 開始可以讓函數單獨出來走兩步了，但前提還是要有interface）

如果你想好好寫 native JavaScript，那麼你通常不需要一個類

// xxx.js
import _ from 'lodash';

export const BOOK_NAME_PREFIX = "JS_"; // 定義常量
export const DEFAULT_USER_AGE = 18;

export const convertVarToObject = function (v) { // 定義一個工具方法，將傳入的值包裝返回一個對象
  // ...
}

const privateSecret = "zhimakaimen"; // 不export的常量自然變成模塊私有的

function privateFunc(){  // 同樣可以定義模塊私有的函數
   // ... 
}

export default {  // 可以export出自定義的對象（包含自定義的屬性）
   render: xxx,  
   property: yyy,
}

直接在 js module 裏定義常量、函數，然後 export 出來給其他模塊用，這麼簡單直接不香嗎？（js module 裏也可以定義私有的變量、常量、函數等）

再次推薦閱讀這篇文章，好好理解 js 模塊，別再像 Java 那樣只用 class 來組織所有代碼了。

FreewheelLee：[搬運] JavaScript 模塊化：CommonJS vs AMD vs ES6zhuanlan.zhihu.com

4. 使用 class 的心智負擔

業務代碼中，現在大家寫 JavaScript class 相信已經不會再直接訪問 prototype 了，而是使用 class 關鍵字 —— 而 class 關鍵字的底層實現仍然是 prototype，仍然要考慮 this 的複雜性，在複雜的繼承場景中甚至仍然得理解 prototype chaining

也就是說，一個新手接觸/維護一個由大量類構成的項目時，他要麼趕緊精通理解JavaScript class，要麼就很可能掉進坑裏。

我在個人體驗裏談到的那個Nodejs項目，實習生新增一個方法後忘記加bind語句，然後程序一直報錯 ReferenceError: XXX is not defined, 他一頭霧水 —— ”明明方法定義就在那兒啊！“

當然這是因爲實習生的基礎問題，他需要更多學習歷練，但話說回來這樣的心智負擔真的有必要嗎？爲什麼不讓程序更簡單明瞭一點？僅僅是爲了讓代碼看起來更 OOP 嗎？

這個油管視頻 https://www.youtube.com/watch?v=Tllw4EPhLiQ （有條件的讀者可以看看）裏說在 JavaScript添加 class 關鍵字就好像

giving clean needles to meth addicts

給（xi du的）癮君子送來一些乾淨的針頭（太犀利了！）（有誇張成分狗頭護體）

簡單來說，JavaScript 並不擅長玩 OOP class 這一套，它有自己非常擅長且自然而然的風格（函數式），如果你想好好學 JavaScript 且正宗地用好 JavaScript ，我個人十分建議，把你花在 JavaScript OOP上的時間用來先搞清楚 JavaScript function 和閉包（React 開發者學好 Hooks）—— 然後再去學 class、prototype 等知識

牢記JavaScript的一個特性 —— Functions are first-class in JavaScript 函數是一等公民

5. 工廠函數會每次都重複生成函數（影響性能）嗎？

可以參考這個回答

brambles：現代瀏覽器生成一個 JS 函數的開銷多大？React hooks 的設計頻繁生成新函數對性能有影響嗎?www.zhihu.com

另外，可以簡單回想一下，在我們日常業務開發中，真的有需要創建那麼多類對象嗎？

你寫的類裏被 new 過幾次？真的每次 new 都有必要嗎？如果沒有，往上看第 3 點。

@賀師俊

賀大提到另一個點

class具有更高的聲明性和靜態可分析性，也跟platform api更爲一致，同時在現代引擎裏也有更好的優化

感謝賀大的指出，底層庫的開發我本人經歷不多，目前接觸更多是還是業務代碼爲主。

至於引擎的代碼優化，我持保留意見，之前在研究React Hooks的時候，不記得在哪看到過React的官方開發者認爲在未來 Functional Component 的優化有比 Class Component 更好的趨勢（原句和原文我暫時找不到了，找到了再補充回來，有讀者看到過也可以評論給我，謝謝） —— 更新：找到了 https://zh-hans.reactjs.org/docs/hooks-intro.html#classes-confuse-both-people-and-machines

後記

挺意外這篇文章有這麼大的關注度，多謝大家的支持和討論。

其實我個人還是有點耿耿於懷的，雖然文章整體表達了我的觀點，但感覺並沒有完全把 JavaScript class 的所有坑介紹清楚（僅提了比較常見的 bind 問題），其實還有 prototype 的機制差異、prototype chain 等問題，但是限於篇幅就沒寫出來。

接下來我會繼續寫一篇後續的相關的文章，接着討論 JavaScript 和 OOP 碰撞的另一簇火花 —— 原來不使用 class ，JavaScript 依然能借鑑前人OOP的最佳實踐和經驗！

文章出爐了！歡迎閱讀：

FreewheelLee：什麼？JavaScript不用class也能實現設計模式！zhuanlan.zhihu.com

參考鏈接：

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Statements/class

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Closures

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Function/bind

https://medium.com/@vapurrmaid/should-you-use-classes-in-javascript-82f3b3df6195

https://medium.com/@charpeni/arrow-functions-in-class-properties-might-not-be-as-great-as-we-think-3b3551c440b1

https://www.toptal.com/javascript/es6-class-chaos-keeps-js-developer-up

應該在JavaScript中使用Class嗎？

看似無處不在的OOP

JavaScript中使用Class的坑

工廠函數（factory functions）

繼承

關注代碼表達性而不是死守教條主義

個人體驗

後記

測試人員都是畫畫大神，讓我看看誰還不會用代碼圖？

centos 如何退出vim

【SpringSecurity-01】httpBasic模式登陸認證

Access和Trunk收發報文規則總結及實驗測試

深度學習入門！三種方式實現minist分類！詳細代碼實現！cnn(卷積神經網絡)，感知機，邏輯迴歸！

應該在JavaScript中使用Class嗎？

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結