应该在JavaScript中使用Class吗？(1)，web开发发展前景

使用类属性+箭头函数的方式来定义方法

即

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 。

总之，不要被教条主义所束缚，牢记编写程序最重要的两点是：

1. 真正将需求转化成了代码

2. 写出可读的，容易维护的，方便理解的代码

---

个人体验

---

在我的工作负责的几个项目中，其中一个Nodejs项目，我发现了大量的不必要的 class ，在constructor中充斥着大量的 bind 语句，而且这些 class 的方法之间并没有太多关系，很多class也没有内部状态；更像是为了声明这些函数是属于同一个模块而已 —— 也就是说根本不必要以 class 的形式组织代码。

于是，在日常任务完成之余，我就花了点时间，把这些class方法全部重构成普通的 function，再利用 ES6 module 的形式重新组织这些代码。现在这些代码干净、清晰了很多。

（关于 Nodejs 的 module 以及如何在 Nodejs 中使用 ES6 module，欢迎阅读我的另一篇文章 ）

FreewheelLee：[搬运] JavaScript 模块化：CommonJS vs AMD vs ES6：

https://zhuanlan.zhihu.com/p/158683510

---

补充：

本文的讨论的场景主要是基于业务开发的上下文，不包括底层库、工具库开发等场景。

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 ES6：https://zhuanlan.zhihu.com/p/158683510

4. 使用 class 的心智负担

业务代码中，现在大家写 JavaScript class 相信已经不会再直接访问 prototype 了，而是使用 class 关键字 —— 而 class 关键字的底层实现仍然是 prototype，仍然要考虑 this 的复杂性，在复杂的继承场景中甚至仍然得理解 prototype chaining

也就是说，一个新手接触/维护一个由大量类构成的项目时，他要么赶紧精通理解JavaScript class，要么就很可能掉进坑里。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

最后

今天的文章可谓是积蓄了我这几年来的应聘和面试经历总结出来的经验，干货满满呀！如果你能够一直坚持看到这儿，那么首先我还是十分佩服你的毅力的。不过光是看完而不去付出行动，或者直接进入你的收藏夹里吃灰，那么我写这篇文章就没多大意义了。所以看完之后，还是多多行动起来吧！

可以非常负责地说，如果你能够坚持把我上面列举的内容都一个不拉地看完并且全部消化为自己的知识的话，那么你就至少已经达到了中级开发工程师以上的水平，进入大厂技术这块是基本没有什么问题的了。

该从何学起的朋友，同时减轻大家的负担。**

[外链图片转存中…(img-CdEljwFA-1712339209569)]

[外链图片转存中…(img-lGBnKQ1a-1712339209569)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

[外链图片转存中…(img-TEnTnKiQ-1712339209570)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

最后

今天的文章可谓是积蓄了我这几年来的应聘和面试经历总结出来的经验，干货满满呀！如果你能够一直坚持看到这儿，那么首先我还是十分佩服你的毅力的。不过光是看完而不去付出行动，或者直接进入你的收藏夹里吃灰，那么我写这篇文章就没多大意义了。所以看完之后，还是多多行动起来吧！

可以非常负责地说，如果你能够坚持把我上面列举的内容都一个不拉地看完并且全部消化为自己的知识的话，那么你就至少已经达到了中级开发工程师以上的水平，进入大厂技术这块是基本没有什么问题的了。

资料领取方式：戳这里前往免费领取