作为JS开发人员，这就是让我彻夜难眠的原因

本文概述

• ES6类的麻烦
• JavaScript流行测验＃1：这些代码块之间的本质区别是什么？
• JavaScript流行测验＃2：以下代码做什么？
• 原型与类
• JavaScript流行测验＃3：如何在课堂中实现隐私？
• JavaScript流行测验＃4：使用关键字类与上述内容等效？
• JavaScript流行测验＃5：SecretiveClass :: looseLips()的作用是什么？
• JavaScript流行测验＃6：经验丰富的JavaScript开发人员更喜欢哪种？原型还是类？
• 寻找好零件

JavaScript是一种语言的怪胎。尽管受到Smalltalk的启发, 但它使用的是类似C的语法。它结合了过程, 功能和面向对象编程(OOP)范例的各个方面。它具有解决几乎所有可能的编程问题的许多方法, 通常是多余的方法, 并且对于哪种方法是优选的没有强烈的意见。它的输入方式弱而动态, 采用迷宫般的方式来强制输入, 甚至使经验丰富的开发人员也无法使用。

JavaScript也有其缺陷, 陷阱和可疑的功能。新程序员要面对一些较困难的概念(例如异步性, 闭包和吊装)。具有其他语言经验的程序员会合理地假设名称和外观相似的事物在JavaScript中的工作方式相同, 并且通常是错误的。数组不是真正的数组；这有什么用, 原型是什么, 新的实际作用是什么？

ES6类的麻烦

到目前为止, 最严重的违规行为是JavaScript的最新发行版ECMAScript 6(ES6)：类的新增内容。围绕类的一些讨论坦率地令人震惊, 并揭示了对语言实际工作方式的根深蒂固的误解：

“现在有了类, JavaScript终于是一种真正的面向对象的语言！”

要么：

“类使我们摆脱了JavaScript破坏的继承模型的思考。”

甚至：

“类是在JavaScript中创建类型的更安全, 更轻松的方法。”

这些陈述不会打扰我, 因为它们暗示原型继承有问题。让我们搁置这些论点。这些陈述令我感到困扰, 因为它们都不是真的, 而且它们证明了JavaScript”为所有人提供的一切”方法在语言设计中的后果：它使程序员对语言的理解更多地失去了对语言的理解。在继续之前, 让我们举例说明。

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

function PrototypicalGreeting(greeting = "Hello", name = "World") {
  this.greeting = greeting
  this.name = name
}

PrototypicalGreeting.prototype.greet = function() {
  return `${this.greeting}, ${this.name}!`
}

const greetProto = new PrototypicalGreeting("Hey", "folks")
console.log(greetProto.greet())

class ClassicalGreeting {
  constructor(greeting = "Hello", name = "World") {
    this.greeting = greeting
    this.name = name
  }

  greet() {
    return `${this.greeting}, ${this.name}!`
  }
}

const classyGreeting = new ClassicalGreeting("Hey", "folks")

console.log(classyGreeting.greet())

答案是没有答案。这些实际上起到了相同的作用, 这只是是否使用ES6类语法的问题。

是的, 第二个例子更具表现力。仅出于这个原因, 你可能会认为类是对语言的一种不错的补充。不幸的是, 这个问题更加微妙。

JavaScript流行测验＃2：以下代码做什么？

function Proto() {
  this.name = 'Proto'
  return this;
}

Proto.prototype.getName = function() {
  return this.name
}

class MyClass extends Proto {
  constructor() {
    super()
    this.name = 'MyClass'
  }
}

const instance = new MyClass()

console.log(instance.getName())

Proto.prototype.getName = function() { return 'Overridden in Proto' }

console.log(instance.getName())

MyClass.prototype.getName = function() { return 'Overridden in MyClass' }

console.log(instance.getName())

instance.getName = function() { return 'Overridden in instance' }


console.log(instance.getName())

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

> MyClass
> Overridden in Proto
> Overridden in MyClass
> Overridden in instance

如果回答不正确, 说明你实际上不知道什么是上课。这不是你的错就像Array一样, class不是语言功能, 它是句法晦涩的词。它试图隐藏原型继承模型和随之而来的笨拙习惯用法, 这暗示着JavaScript正在做某些事情, 而事实并非如此。

你可能已经被告知JavaScript引入了类, 以使来自Java之类的经典OOP开发人员更喜欢ES6类继承模型。如果你是这些开发人员之一, 那么该示例可能会使你感到恐惧。这应该。它表明JavaScript的class关键字没有提供类要提供的任何保证。它还演示了原型继承模型中的关键区别之一：原型是对象实例, 而不是类型。

原型与类

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

ES6类的子级是另一个类型定义, 它使用新的属性和方法扩展了父级, 这些属性和方法又可以在运行时实例化。原型的子代是另一个对象实例, 它将未在子代上实现的所有属性委托给父代。

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

类构造函数创建该类的实例。 JavaScript中的构造函数只是一个简单的旧函数, 它返回一个对象。 JavaScript构造函数的唯一特别之处在于, 当使用new关键字调用时, 它将其原型分配为返回对象的原型。如果这听起来让你感到困惑, 那么你并不孤单, 而是这样, 这也是为什么人们对原型理解不充分的重要原因。

确切地说, 原型的孩子不是原型的副本, 也不是与原型形状相同的对象。子对象对原型具有活泼的引用, 子对象上不存在的任何原型属性都是对原型上同名属性的单向引用。

考虑以下：

let parent = { foo: 'foo' }
let child = { }
Object.setPrototypeOf(child, parent)

console.log(child.foo) // 'foo'

child.foo = 'bar'

console.log(child.foo) // 'bar'

console.log(parent.foo) // 'foo'

delete child.foo

console.log(child.foo) // 'foo'

parent.foo = 'baz'

console.log(child.foo) // 'baz'

注意：在现实生活中, 你几乎永远不会写这样的代码-这是很糟糕的做法-但它简洁地演示了该原理。

在上一个示例中, 虽然未定义child.foo, 但它引用了parent.foo。一旦我们在child上定义了foo, child.foo的值就为’bar’, 但是parent.foo保留了其原始值。删除child.foo之后, 它将再次引用parent.foo, 这意味着当我们更改父项的值时, child.foo会引用新值。

让我们看一下发生了什么(为了更清楚地说明, 我们将它们假装成字符串而不是字符串文字, 这里的区别不重要)：

它的工作方式, 尤其是new和this的特性, 是另一天的话题, 但是如果你想了解更多, Mozilla会提供一篇有关JavaScript原型继承链的详尽文章。

关键的一点是, 原型没有定义类型。它们本身就是实例, 它们在运行时是可变的, 具有所有隐含和必然性。

还在我这儿？让我们回到剖析JavaScript类的角度。

JavaScript流行测验＃3：如何在课堂中实现隐私？

我们上面的原型和类属性并不是被”封装在窗外”, 而是被”封装”了。我们应该解决该问题, 但是如何解决？

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

JavaScript没有任何隐私概念, 但是确实有闭包：

function SecretiveProto() {
  const secret = "The Class is a lie!"
  this.spillTheBeans = function() {
    console.log(secret)
  }
}

const blabbermouth = new SecretiveProto()
try {
  console.log(blabbermouth.secret)
}
catch(e) {
  // TypeError: SecretiveClass.secret is not defined
}

blabbermouth.spillTheBeans() // "The Class is a lie!"

你知道发生了什么吗？如果没有, 你将不了解闭包。没关系, 真的-它们不像它们看上去那样吓人, 它们非常有用, 你应该花一些时间来了解它们。

JavaScript流行测验＃4：使用关键字类与上述内容等效？

抱歉, 这是另一个技巧问题。你可以做基本上相同的事情, 但是看起来像这样：

class SecretiveClass {
  constructor() {
    const secret = "I am a lie!"
    this.spillTheBeans = function() {
      console.log(secret)
    }
  }

  looseLips() {
    console.log(secret)
  }
}

const liar = new SecretiveClass()
try {
  console.log(liar.secret)
}
catch(e) {
  console.log(e) // TypeError: SecretiveClass.secret is not defined
}
liar.spillTheBeans() // "I am a lie!"

让我知道, 这看起来比SecretiveProto更容易或更清晰。在我个人看来, 情况有些糟, 它打破了JavaScript中类声明的惯用用法, 并且效果不像你期望的那样, 例如Java。这将通过以下内容清楚地表明：

JavaScript流行测验＃5：SecretiveClass :: looseLips()的作用是什么？

让我们找出：

try {
  liar.looseLips()
}
catch(e) {
  // ReferenceError: secret is not defined
}

好吧……那很尴尬。

JavaScript流行测验＃6：经验丰富的JavaScript开发人员更喜欢哪种？原型还是类？

你猜对了, 这是另一个技巧问题-经验丰富的JavaScript开发人员往往会尽量避免两者。这是使用惯用JavaScript进行上述操作的好方法：

function secretFactory() {
  const secret = "Favor composition over inheritance, `new` is considered harmful, and the end is near!"
  const spillTheBeans = () => console.log(secret)

  return {
    spillTheBeans
  }
}

const leaker = secretFactory()
leaker.spillTheBeans()

这不仅仅是避免固有的继承丑陋或强制封装。考虑一下你可能会对secretFactory和leaker做什么, 而原型或类则很难做到。

一方面, 你可以对其进行重组, 因为你不必担心其上下文：

const { spillTheBeans } = secretFactory()

spillTheBeans() // Favor composition over inheritance, (...)

很好除了避免新的和这种愚弄之外, 它还允许我们将对象与CommonJS和ES6模块互换使用。这也使合成变得容易一些：

function spyFactory(infiltrationTarget) {
  return {
    exfiltrate: infiltrationTarget.spillTheBeans
  }
}

const blackHat = spyFactory(leaker)

blackHat.exfiltrate() // Favor composition over inheritance, (...)

console.log(blackHat.infiltrationTarget) // undefined (looks like we got away with it)

blackHat的客户不必担心漏洞的来源, 而spyFactory则不必乱搞Function :: bind上下文杂乱或深层嵌套的属性。请注意, 我们在简单的同步过程代码中不必为此担心, 但是它会导致异步代码中的各种问题, 而这些问题最好避免。

稍加思考, 即可将spyFactory开发为一种高度复杂的间谍工具, 可以处理各种渗透目标(换句话说, 是立面)。

当然, 你也可以使用一个类, 或者说一个各种各样的类来做到这一点, 所有这些类都继承自抽象类或接口……除了JavaScript没有任何抽象或接口的概念。

让我们回到问候示例, 看看如何在工厂中实现它：

function greeterFactory(greeting = "Hello", name = "World") {
  return {
    greet: () => `${greeting}, ${name}!`
  }
}

console.log(greeterFactory("Hey", "folks").greet()) // Hey, folks!

你可能已经注意到, 随着我们的发展, 这些工厂变得越来越简洁, 但请不要担心-他们是同一件事。伙计们, 训练轮脱落了！

这已经比相同代码的原型或类版本要少。其次, 它更有效地实现了其特性的封装。而且, 在某些情况下, 它具有较低的内存和性能占用空间(乍看之下似乎并不像它, 但是JIT编译器正在悄悄地进行幕后工作, 以减少重复和推断类型)。

这样更安全, 通常更快, 编写这样的代码也更容易。为什么我们需要再次上课？哦, 当然是可重用性。如果我们想要不快乐和热情的迎宾者变体会怎样？好吧, 如果我们使用的是ClassicalGreeting类, 我们可能会直接跳入对类层次结构的梦想中。我们知道我们需要参数化标点符号, 因此我们将进行一些重构并添加一些子代：

// Greeting class
class ClassicalGreeting {
  constructor(greeting = "Hello", name = "World", punctuation = "!") {
    this.greeting = greeting
    this.name = name
    this.punctuation = punctuation
  }

  greet() {
    return `${this.greeting}, ${this.name}${this.punctuation}`
  }
}

// An unhappy greeting
class UnhappyGreeting extends ClassicalGreeting {
  constructor(greeting, name) {
    super(greeting, name, " :(")
  }
}

const classyUnhappyGreeting = new UnhappyGreeting("Hello", "everyone")

console.log(classyUnhappyGreeting.greet()) // Hello, everyone :(

// An enthusiastic greeting
class EnthusiasticGreeting extends ClassicalGreeting {
  constructor(greeting, name) {
	super(greeting, name, "!!")
  }

  greet() {
	return super.greet().toUpperCase()
  }
}

const greetingWithEnthusiasm = new EnthusiasticGreeting()

console.log(greetingWithEnthusiasm.greet()) // HELLO, WORLD!!

这是一个很好的方法, 直到有人出现并要求提供一个不完全适合层次结构的功能, 然后整个事情变得毫无意义。在尝试与工厂编写相同功能时, 请仔细考虑一下：

const greeterFactory = (greeting = "Hello", name = "World", punctuation = "!") => ({
  greet: () => `${greeting}, ${name}${punctuation}`
})

// Makes a greeter unhappy
const unhappy = (greeter) => (greeting, name) => greeter(greeting, name, ":(")

console.log(unhappy(greeterFactory)("Hello", "everyone").greet()) // Hello, everyone :(

// Makes a greeter enthusiastic
const enthusiastic = (greeter) => (greeting, name) => ({
  greet: () => greeter(greeting, name, "!!").greet().toUpperCase()
})

console.log(enthusiastic(greeterFactory)().greet()) // HELLO, WORLD!!

尽管这段代码短了一点, 但它显然不是更好的代码。实际上, 你可能会争辩说它很难阅读, 也许这是一种过时的方法。我们不能只拥有一个不快乐的GreetFactory和一个热情的GreetFactory吗？

然后, 你的客户说：”我需要一个不高兴的新迎宾员, 并希望整个房间都知道这一点！”

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

如果我们需要多次使用这种热情不满的问候语, 我们可以使自己更轻松：

const aggressiveGreeterFactory = enthusiastic(unhappy(greeterFactory))

console.log(aggressiveGreeterFactory("You're late", "Jim").greet())

有一些方法可以与原型或类一起使用。例如, 你可以重新考虑将UnhappyGreeting和EnthusiasticGreeting作为装饰器。与上面使用的功能样式方法相比, 它仍然需要更多样板, 但这就是你为实型类的安全性和封装所付出的代价。

关键是, 在JavaScript中, 你不会获得这种自动安全性。强调类使用的JavaScript框架在解决此类问题方面具有很多”魔力”, 可以迫使类表现自己。我敢, 有一段时间请看Polymer的ElementMixin源代码。这是JavaScript至上的怪癖级别, 我的意思是没有讽刺或讽刺意味。

当然, 我们可以用Object.freeze或Object.defineProperties解决以上讨论的某些问题, 以或多或少地产生效果。但是, 为什么在不使用功能的情况下模仿表单, 而忽略工具, JavaScript确实为我们提供了我们在Java等语言中找不到的工具？当你的工具箱旁边有真正的螺丝刀时, 你会使用标有”螺丝刀”的锤子来驱动螺丝吗？

寻找好零件

JavaScript开发人员经常在口语上和参考同名书时都强调该语言的优点。我们试图避免由其更可疑的语言设计选择所设置的陷阱, 并坚持让我们编写简洁, 可读, 错误最小化, 可重用代码的部分。

关于JavaScript的哪些部分合格, 有合理的论据, 但我希望我已经说服你该类不是其中之一。失败的话, 希望你理解JavaScript中的继承可能会造成混乱, 并且该类既不能解决该问题, 也使你不必去理解原型。如果你发现有关面向对象的设计模式在没有类或ES6继承的情况下可以很好地工作的提示, 则格外值得赞扬。

我并不是要你完全避免上课。有时你需要继承, 而类提供了更简洁的语法来实现这一点。特别是, 类X扩展Y比旧的原型方法好得多。除此之外, 许多流行的前端框架都鼓励使用它, 你应该避免仅凭原则编写怪异的非标准代码。我只是不喜欢这要去哪里。

在我的噩梦中, 整个JavaScript库都是使用类编写的, 期望它的行为与其他流行语言相似。发现了全新的bug类(双关语)。如果我们不小心落入类陷阱中, 很可能会遗留在格式错误的JavaScript墓地中的旧版本。经验丰富的JavaScript开发人员为这些怪物所困扰, 因为流行的并不总是善良的。

最终, 我们所有人都放弃了挫败感, 开始重新发明Rust, Go, Haskell或其他人知道的轮子, 然后编译为Wasm进行网络使用, 新的Web框架和库激增为多语言的无限。

的确使我彻夜难眠。