JavaScript中什么时候使用Class？

无处不在的OOP

OOP 即 面向对象编程 （Object Oriented Programming）毫无疑问是软件设计和发展中的一大进步。事实上，一些编程语言如 Java 、C++ 就是基于 OOP 的核心概念 class 开发出来。

在高校的 CS 相关专业中，无论教授什么编程语言，OOP的学习是绝对不会被落下的。

同时，OOP在业界中也的确被大量使用，尤其是的后端服务领域、桌面软件、移动APP开发等。

因此，OOP看起来在软件行业无处不在，在这种有点教条主义的氛围下，很多程序员甚至以为 class 是编程固有的概念 —— 然而并不是。

OOP 只是一套帮助开发者设计和编写软件的方法论，但并不代表它能解决所有领域的问题，也不是能在所有编程语言的任何场景下都适用。我们应避免陷入这种教条主义。

使用Class的坑

ES6 之后，JavaScript 也引入了 class 关键字用于声明一个类。但需要注意的是，这样声明出来的类其实在底层还是使用了 JavaScript 的函数 和 原型链 （来模拟类的行为）

看个例子：

class Person {
  constructor (name) {
    this.name = name
  }
  
  talk () {
    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 。

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

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

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

---

之前在研究React Hooks的时候，不记得在哪看到过React的官方开发者认为在未来 Functional Component 的优化有比 Class Component 更好的趋势。

完结撒花，有疑问留言探讨哈~~~