作为一名JS开发人员，是什么使我夜不能寐!

JavaScript 是一种奇怪的语言。虽然受到 Smalltalk 的启发，但它用了类似 C 的语法。它结合了程序、函数和面向对象编程（OOP）的方方面面。它有许多能够解决几乎任何编程问题的方法，这些方法通常是多余的，并没有强烈推荐哪些是首选。它是弱动态类型，但采用了类似强制类型的方法，使经验丰富的开发人员也可以使用。

JavaScript 也有其瑕疵、陷阱和可疑的功能。新手程序员需要努力解决一些更为困难的概念 —— 异步性、封闭性和提升。具有其他语言经验的程序员合理地假设具有相似名称的东西，但是看上去与 JavaScript 相同的工作方法往往是错误的。数组不是真正的数组，什么是 this ，什么是原型， new 实际上做了些什么？

ES6 类的麻烦

到目前为止，最糟糕的罪魁祸首是 JavaScript 的最新版本——ECMAScript 6（ES6）的 类 。一些关于类的讨论坦率地令人震惊，并揭示了对语言实际运作机制的根深蒂固的误解：

“JavaScript 现在终于成为一种 真正的 面向对象的语言，因为它有类！”

要么是：

“让我们从 JavaScript 中被破坏的继承模型中解脱出来。”

甚至是：

“在 JavaScript 中创建类型是一种更安全、更简单的方法。”

这些言论并没有影响到我，因为它们暗示了原型继承中存在问题，让我们抛开这些论点。这些话让我感到困扰，因为它们都不是真的，它们证明了 JavaScript 的“everything for everyone”的语言设计方法的后果：它削弱了程序员对语言的理解。在我进一步说明之前，先举一个例子。

JavaScript 小测验 #1：这些代码块之间的本质区别是什么？

 1function PrototypicalGreeting(greeting = "Hello", name = "World") {2  this.greeting = greeting3  this.name = name4}56PrototypicalGreeting.prototype.greet = function() {7  return `${this.greeting}, ${this.name}!`8}9
10const greetProto = new PrototypicalGreeting("Hey", "folks")
11console.log(greetProto.greet())
12class ClassicalGreeting {
13  constructor(greeting = "Hello", name = "World") {
14    this.greeting = greeting
15    this.name = name
16  }
17
18  greet() {
19    return `${this.greeting}, ${this.name}!`
20  }
21}
22
23const classyGreeting = new ClassicalGreeting("Hey", "folks")
24
25console.log(classyGreeting.greet())

这里的答案是 并不是唯一的 。这些代码确实有效，它只是一个是否使用了 ES6 类语法的问题。

没错，第二个例子更具表现力，因此你可能会认为 class 是语言的一个很好的补充。不幸的是，这个问题会变得更加微妙。

JavaScript 小测验 #2：以下代码有什么作用？

 1function Proto() {2  this.name = 'Proto'3  return this;4}56Proto.prototype.getName = function() {7  return this.name8}9
10class MyClass extends Proto {
11  constructor() {
12    super()
13    this.name = 'MyClass'
14  }
15}
16
17const instance = new MyClass()
18
19console.log(instance.getName())
20
21Proto.prototype.getName = function() { return 'Overridden in Proto' }
22
23console.log(instance.getName())
24
25MyClass.prototype.getName = function() { return 'Overridden in MyClass' }
26
27console.log(instance.getName())
28
29instance.getName = function() { return 'Overridden in instance' }
30
31
32console.log(instance.getName())

正确的答案是它打印到控制台的输出：

1> MyClass
2> Overridden in Proto
3> Overridden in MyClass
4> Overridden in instance

如果你回答错误，就意味着不明白 class 究竟是什么。但这不是你的错。就像 Array 、 class 不是语言特征一样，它是 蒙昧的语法 。它试图隐藏原型继承模型和随之而来的笨拙的惯用语法，这意味着 JavaScript 正在做的事情并非是你想的那样。

你可能已经被告知在 JavaScript 中引入了 class ，以使来自 Java 等语言的经典 OOP 开发人员更加熟悉 ES6 类继承模型。如果你是这样的开发者，那个例子可能会让你感到恐惧。例子表明 JavaScript 的 class 关键字没有提供类所需要的任何保证。它还演示了原型继承模型中的一个主要差异：原型是 对象实例 ，而不是 类型 。

原型与类

基于类和基于原型的继承之间最重要的区别是类定义了一个 类型 ，它可以在运行时实例化，而原型本身就是一个对象实例。

ES6 类的子类是另一个 类型 定义，它使用新的属性和方法扩展父类，然后可以在运行时实例化它们。原型的子代是另一个对象 实例 ，它将任何未在子代上实现的属性委托给父代。

旁注：你可能想知道为什么我提到了类方法，但没有提到原型方法。那是因为 JavaScript 没有方法的概念。函数在 JavaScript 中是一流的，它们可以具有属性或是其他对象的属性。

类构造函数用来创建类的实例。JavaScript 中的构造函数只是一个返回对象的普通函数。JavaScript 构造函数唯一的特别之处在于，当使用 new 关键字调用时，它会将其原型指定为返回对象的原型。如果这对你来说听起来有点混乱，那么你并不孤单 —— 它就是原型很难理解的原因。

为了说明一点，原型的子代不是原型的 副本 ，也不是与原型相同的对象。子代对原型有生命参考，并且子代上不存在的原型属性是对原型上具有相同名称属性的单向引用。。

思考以下代码：

 1let parent = { foo: 'foo' }2let child = { }3Object.setPrototypeOf(child, parent)45console.log(child.foo) // 'foo'67child.foo = 'bar'89console.log(child.foo) // 'bar'
10
11console.log(parent.foo) // 'foo'
12
13delete child.foo
14
15console.log(child.foo) // 'foo'
16
17parent.foo = 'baz'
18
19console.log(child.foo) // 'baz'

注意：你几乎不会在现实中写这样的代码 —— 这是一种可怕的做法 —— 但它简洁地证明了这一原则。

在前面的例子中，当 child.foo 是 undefined 时，它引用了 parent.foo 。一旦在 child 上定义了 foo ， child.foo 的值为 'bar' ，但 parent.foo 保留了原始值。一旦我们 delete child.foo ，它将会再次引用 parent.foo ，这意味着当我们更改父项的值时， child.foo 指的是新值。

让我们来看看刚才发生了什么（为了更清楚地说明，我们假设这些是 Strings 而不是字符串字面量，这里的区别并不重要）：

显示如何在JavaScript中处理缺少的引用的原型链

它的工作方式，特别是 new 和 this 的特点是另一个主题，但如果你想学到更多的内容，可以查阅 Mozilla 的关于 JavaScript 的原型继承链的一篇详尽的文章【 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain 】。

关键的一点是原型没有定义 type ，它们本身就是 instances ，并且它们在运行时是可变的。

还有勇气往下读吗？接下来让我们再回过头来剖析 JavaScript 类。

JavaScript 小测验 #3：如何在类中实现私有？

上面的原型和类属性并没有被“封装”为外部不可访问的私有成员。应该怎样解决这个问题呢？

这里没有代码示例。答案是，你做不到。

JavaScript 没有任何私有的概念，但是它有闭包：

 1function SecretiveProto() {2  const secret = "The Class is a lie!"3  this.spillTheBeans = function() {4    console.log(secret)5  }6}78const blabbermouth = new SecretiveProto()9try {
10  console.log(blabbermouth.secret)
11}
12catch(e) {
13  // TypeError: SecretiveClass.secret is not defined
14}
15
16blabbermouth.spillTheBeans() // "The Class is a lie!"

你明白刚才发生了什么吗？如果不明白的话就没搞懂闭包。好吧，但是它们并不那么令人生畏，而且非常有用，你应该花一些时间来了解它们【 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures 】。

JavaScript 小测验 #4：怎样用 `class` 关键字写出与上面功能相同的代码？

对不起，这是另一个技巧问题。你可以做同样的事情，但它看起来是这样的：

 1class SecretiveClass {2  constructor() {3    const secret = "I am a lie!"4    this.spillTheBeans = function() {5      console.log(secret)6    }7  }89  looseLips() {
10    console.log(secret)
11  }
12}
13
14const liar = new SecretiveClass()
15try {
16  console.log(liar.secret)
17}
18catch(e) {
19  console.log(e) // TypeError: SecretiveClass.secret is not defined
20}
21liar.spillTheBeans() // "I am a lie!"

如果你觉得这看起来比 SecretiveProto 更简单或更清晰，那么请告诉我。在我个人看来，它有点糟糕 —— 它打破了 JavaScript 中 class 声明的习惯用法，并且它不像你期望的那样来自 Java。这将通过以下方式表明：

JavaScript 小测验＃5：`SecretiveClass::looseLips()` 是做什么用的？

我们来看看这段代码：

1try {
2  liar.looseLips()
3}
4catch(e) {
5  // ReferenceError: secret is not defined
6}

嗯……这很尴尬。

JavaScript Pop Quiz＃6：经验丰富的 JavaScript 开发人员更喜欢原型还是类？

你猜对了，这又是一个关于技巧问题 —— 经验丰富的 JavaScript 开发人员倾向于尽可能避免两者。以下是使用 JavaScript 执行上述操作的惯用的好方法：

 1function secretFactory() {2  const secret = "Favor composition over inheritance, `new` is considered harmful, and the end is near!"3  const spillTheBeans = () => console.log(secret)45  return {6    spillTheBeans7  }8}9
10const leaker = secretFactory()
11leaker.spillTheBeans()

这不仅仅是为了避免继承的丑陋或强制封装。想一想你能用 secretFactory 和 leaker 做些什么，你用原型或类做可不能轻易的做到。

首先，你可以解构它，因为你不必担心 this 的上下文：

1const { spillTheBeans } = secretFactory()
2
3spillTheBeans() // Favor composition over inheritance, (...)

这真是太好了。除了避免使用 new 和 this 做蠢事之外，它还允许我们将对象与 CommonJS 和 ES6 模块互换使用。它还使开发更容易：

 1function spyFactory(infiltrationTarget) {2  return {3    exfiltrate: infiltrationTarget.spillTheBeans4  }5}67const blackHat = spyFactory(leaker)89blackHat.exfiltrate() // Favor composition over inheritance, (...)
10
11console.log(blackHat.infiltrationTarget) // undefined (looks like we got away with it)

使用 blackHat 的程序员不必担心 exfiltrate 来自哪里， spyFactory 也不必乱用 Function::bind 的上下文小伎俩或深层嵌套属性。请注意，我们无需在简单的同步过程代码中担心 this ，但它会导致异步代码中的各种问题。

经过一番思考， spyFactory 可以发展成为一种高度复杂的间谍工具，可以处理各种渗透目标 - 换句话说，就是外观模式。

当然你也可以用类来做，或者更确切地说，是各种各样的类，所有类都继承自 abstract class 或 interface 等，不过 JavaScript 没有任何抽象或接口的概念。

让我们用一个更好的例子来看看如何用工厂模式实现它：

1function greeterFactory(greeting = "Hello", name = "World") {
2  return {
3    greet: () => `${greeting}, ${name}!`
4  }
5}
6
7console.log(greeterFactory("Hey", "folks").greet()) // Hey, folks!

这比原型或类的版本更简洁。它可以更有效地实现其属性的封装。此外，它在某些情况下具有较低的内存和性能影响（乍一看似乎不太可能，但 JIT 编译器正悄悄地在幕后做了减少重复和推断类型的工作）。

因此它更安全，通常情况下也更快，并且编写这样的代码更容易。为什么我们又需要类了呢？哦，当然是可重用性。如果我们想要一个unhappy 且 enthusiastic 的 greeting会怎样？好吧，如果我们用的是 ClassicalGreeting 类，可能会直接跳到梦想中的类层次结构中。我们知道自己需要参数化符号，所以会做一些重构并添加一些子类：

 1// Greeting class2class ClassicalGreeting {3  constructor(greeting = "Hello", name = "World", punctuation = "!") {4    this.greeting = greeting5    this.name = name6    this.punctuation = punctuation7  }89  greet() {
10    return `${this.greeting}, ${this.name}${this.punctuation}`
11  }
12}
13
14// An unhappy greeting
15class UnhappyGreeting extends ClassicalGreeting {
16  constructor(greeting, name) {
17    super(greeting, name, " :(")
18  }
19}
20
21const classyUnhappyGreeting = new UnhappyGreeting("Hello", "everyone")
22
23console.log(classyUnhappyGreeting.greet()) // Hello, everyone :(
24
25// An enthusiastic greeting
26class EnthusiasticGreeting extends ClassicalGreeting {
27  constructor(greeting, name) {
28    super(greeting, name, "!!")
29  }
30
31  greet() {
32    return super.greet().toUpperCase()
33  }
34}
35
36const greetingWithEnthusiasm = new EnthusiasticGreeting()
37
38console.log(greetingWithEnthusiasm.greet()) // HELLO, WORLD!!

这是一个很好的方法，直到有人出现并要求实现一个不能完全适合层次结构的功能，整个事情都没有任何意义。当我们尝试用工厂模式编写相同的功能时，在这个想法中放一个引脚：

 1const greeterFactory = (greeting = "Hello", name = "World", punctuation = "!") => ({2  greet: () => `${greeting}, ${name}${punctuation}`3})45// Makes a greeter unhappy6const unhappy = (greeter) => (greeting, name) => greeter(greeting, name, ":(")78console.log(unhappy(greeterFactory)("Hello", "everyone").greet()) // Hello, everyone :(9
10// Makes a greeter enthusiastic
11const enthusiastic = (greeter) => (greeting, name) => ({
12  greet: () => greeter(greeting, name, "!!").greet().toUpperCase()
13})
14
15console.log(enthusiastic(greeterFactory)().greet()) // HELLO, WORLD!!

虽然它的代码更短，但得到的好处并不明显。实际上你可能会觉得它更难以阅读，也许这是一种迟钝的方法。难道我们不能只有一个 unhappyGreeterFactory 和一个 passionsticGreeterFactory ？

然后你的客户出现并说：“我需要一个不开心的新员工，希望整个办公室都能认识它！”

1console.log(enthusiastic(unhappy(greeterFactory))().greet()) // HELLO, WORLD :(

如果我们需要不止一次地使用这个 enthusiastically 且 unhappy 的  greeter，可以更容易实现：

1const aggressiveGreeterFactory = enthusiastic(unhappy(greeterFactory))
2
3console.log(aggressiveGreeterFactory("You're late", "Jim").greet())

这种合成风格的方法适用于原型或类。例如，你可以将 UnhappyGreeting 和 EnthusiasticGreeting 重新考虑为装饰器。它仍然需要比上面的函数风格方法更多的样板，但这是你为 真正的 类的安全性和封装所付出的代价。

问题是，在 JavaScript 中，你没有得到自动安全性。强调 class 用法的 JavaScript 框架会对这些问题变很多“魔术”，并强制类使用自己的行为。看看 Polymer 的 ElementMixin 源代码【 https://github.com/Polymer/polymer/blob/master/lib/mixins/element-mixin.js 】，我敢说。它简直是 JavaScript 神器级别的代码，我没有任何讽刺的意思。

当然，我们可以用 Object.freeze 或 Object.defineProperties 来解决上面讨论的一些问题，以达到更大或更小的效果。但是为什么要在没有函数的情况下模仿表单，而忽略了 JavaScript 本身为我们提供的工具？当你的工具箱旁边有真正的螺丝刀时，你会用一把标有 “螺丝刀” 的锤子来驱动螺丝吗？