JavaScript中的 Private(私有) 和 Public(公有) 属性

我最喜欢的 JavaScript 社区的一部分原因是每个人似乎总是问 “为什么?” 。 为什么我们要按照这种方式做事? 一般来说,这个问题的答案需要充满理性和回顾历史背景。 但有时,答案往往更简单 – “因为我们一直以来都是这么做的。”

上一篇文章 中,我们学习了如何在 ES5 和 ES6 中创建 JavaScript 类。 我们还讨论了如何通过构造函数向这些类的实例添加 state(状态) ,以及如何通过类的原型在实例之间共享方法。 这是一个简单的 Player 类,它包含了我们讨论的有关 ES6 类的所有内容。

class Player {
  constructor() {
    this.points = 0
    this.assists = 0
    this.rebounds = 0
    this.steals = 0
  }
  addPoints(amount) {
    this.points += amount
  }
  addAssist() {
    this.assists++
  }
  addRebound() {
    this.rebounds++
  }
  addSteal() {
    this.steals++
  }
}

我们看看这段代码,我们能不能让它更直观一点呢?方法很好理解,都很自然。那么构造函数呢?什么是 constructor ?为什么我们必须在这里定义实例值?现在,这些问题已经有了答案,但是为什么我们不能向实例中添加 state(状态) ,就像方法那样?比如:

class Player {
  points = 0
  assists = 0
  rebounds = 0
  steals = 0
  addPoints(amount) {
    this.points += amount
  }
  addAssist() {
    this.assists++
  }
  addRebound() {
    this.rebounds++
  }
  addSteal() {
    this.steals++
  }
}

事实上,这是 Class Fields Declaration 提案的基础,该提案目前处于 TC-39 流程的 第3阶段 。 此提议允许您直接将实例属性添加为类的属性,而无需使用构造方法。 非常漂亮,但是如果我们看一些 React 代码,这个提案真的很棒。 这是一个典型的 React 组件。 它具有本地 state(状态) ,一些方法以及一些静态属性被添加到类中。

class PlayerInput extends Component {
  constructor(props) {
    super(props)
    this.state = {
      username: ''
    }

    this.handleChange = this.handleChange.bind(this)
  }
  handleChange(event) {
    this.setState({
      username: event.target.value
    })
  }
  render() {
    ...
  }
}

PlayerInput.propTypes = {
  id: PropTypes.string.isRequired,
  label: PropTypes.string.isRequired,
  onSubmit: PropTypes.func.isRequired,
}

PlayerInput.defaultProps = {
  label: 'Username',
}

让我们看看新的 Class Fields 提议如何改进上面的代码首先,我们可以将 state(状态) 变量从构造函数中取出,并将其直接定义为类的属性(或“字段”)。

class PlayerInput extends Component {
  state = {
    username: ''
  }
  constructor(props) {
    super(props)

    this.handleChange = this.handleChange.bind(this)
  }
  handleChange(event) {
    this.setState({
      username: event.target.value
    })
  }
  render() {
    ...
  }
}

PlayerInput.propTypes = {
  id: PropTypes.string.isRequired,
  label: PropTypes.string.isRequired,
  onSubmit: PropTypes.func.isRequired,
}

PlayerInput.defaultProps = {
  label: 'Username',
}

很酷,但没什么好兴奋的。 我们继续吧。 在上一篇文章中,我们讨论了如何使用 static 关键字向类本身添加静态方法。 但是,根据 ES6 类规范,这只对方法有效,对于值则无效。 这就是为什么在上面的代码中,我们必须在我们定义完 PlayerInput 之后,再在 class 外面将 propTypesdefaultProps 添加到 PlayerInput ,而不是在 class 体内定义他们的原因。 再说一遍,它们不能像静态方法那样直接放入 class 体内呢? 好消息是,这也包含在 Class Fields 提案中。 所以现在不仅可以在类体中定义静态方法,还可以定义静态值。 这对我们的代码意味着我们可以将 propTypesdefaultProps 移动到 class 体内定义。

class PlayerInput extends Component {
  static propTypes = {
    id: PropTypes.string.isRequired,
    label: PropTypes.string.isRequired,
    onSubmit: PropTypes.func.isRequired,
  }
  static defaultProps = {
    label: 'Username'
  }
  state = {
    username: ''
  }
  constructor(props) {
    super(props)

    this.handleChange = this.handleChange.bind(this)
  }
  handleChange(event) {
    this.setState({
      username: event.target.value
    })
  }
  render() {
    ...
  }
}

这样代码看上去好多了,但我们仍然有丑陋的 constructor 方法和 super 调用。 同样,我们现在需要构造函数的原因是为了将 handleChange 方法绑定到恰当的上下文中。 如果我们能找到另一种方法来确保始终在恰当的上下文中调用 handleChange ,那么我们可以摆脱掉 constructor

如果您以前使用过箭头函数,就会知道它们没有自己的 this 关键字。相反,this 关键字是按 lexically(词法) 绑定的。这是一种奇特的说法,当你在箭头函数中使用 this 关键字时,事情会按照你所期望的方式运行。利用这些知识并将其与 “Class Fields” 提案相结合起来,如果我们将 handleChange 方法替换为箭头函数呢?这看起来有点奇怪,但是通过这样做,我们可以解决绑定问题,因为,箭头函数是通过 lexically(词法) 绑定 this 的。

class PlayerInput extends Component {
  static propTypes = {
    id: PropTypes.string.isRequired,
    label: PropTypes.string.isRequired,
    onSubmit: PropTypes.func.isRequired,
  }
  static defaultProps = {
    label: 'Username'
  }
  state = {
    username: ''
  }
  handleChange = (event) => {
    this.setState({
      username: event.target.value
    })
  }
  render() {
    ...
  }
}

你看上面的代码,这比我们开始的原始类要好得多,这都要感谢 “Class Fields” 提案,它将很快成为 EcmaScript 规范的一部分。

从开发者体验的角度来看,Class Fields 提案优势很明显。 然而,他们有一些缺点,很少被谈论。 在上一篇文章中,我们讨论了 ES6 类实际上只是 Pseudoclassical Instantiation(伪类实例化) 模式的语法糖。也就是说,当你向类添加方法时,这就像在函数原型中添加方法一样。

class Animal {
  eat() {}
}

// Is equivalent to

function Animal () {}
Animal.prototype.eat = function () {}

这是高效的,因为 eat 定义一次并在类的所有实例之间共享。 这与 Class Fields 有什么关系? 好吧,正如我们上面所看到的, Class Fields 被添加到实例中。 这意味着对于我们创建的每个实例,我们将创建一个新的 eat 方法。

class Animal {
  eat() {}
  sleep = () => {}
}

// Is equivalent to

function Animal () {
  this.sleep = function () {}
}

Animal.prototype.eat = function () {}

请注意 sleep 如何放在实例上,而不是放在 Animal.prototype 上。这是件坏事吗?嗯,有可能。在不进行度量的情况下对性能进行宽泛的描述通常不是一个好主意。您需要在应用程序中回答的问题是,您从 Class Fields 中获得的开发人员体验是否超过了潜在的性能损失。

如果你想在你的应用程序中使用我们之前谈到的任何内容,你需要使用 babel-plugin-transform-class-properties 插件。

Private(私有) 属性

Class Fields 提案的另一个内容时是 “private fields (私有属性)” 。 有时,当您构建一个类时,您希望拥有不暴露给外界的私有值。 从历史上看, JavaScript 缺乏真正私有值 的能力,所以我们通过约定,用下划线标记它们。

class Car {
  _milesDriven = 0
  drive(distance) {
    this._milesDriven += distance
  }
  getMilesDriven() {
    return this._milesDriven
  }
}

在上面的示例中,我们依靠 Car class(类)的实例通过调用 getMilesDriven 方法来获取汽车的里程数。但是,因为没有什么能使 _milesDriven成为私有的,所以任何实例都可以访问它。

const tesla = new Car()
tesla.drive(10)
console.log(tesla._milesDriven)

有个奇特的(hacky)方法,就是使用 WeakMaps 可以解决这个问题,但如果存在更简单的解决方案,那将会很好。 同样,Class Fields 提案正在拯救我们。 根据提议,您可以使用 创建私有字段。 是的,你没有看错, 。 我们来看看它对我们的代码有什么影响,

class Car {
  #milesDriven = 0
  drive(distance) {
    this.#milesDriven += distance
  }
  getMilesDriven() {
    return this.#milesDriven
  }
}

我们可以用速记语法更进一步简化

class Car {
  #milesDriven = 0
  drive(distance) {
    #milesDriven += distance
  }
  getMilesDriven() {
    return #milesDriven
  }
}

const tesla = new Car()
tesla.drive(10)
tesla.getMilesDriven() // 10
tesla.#milesDriven // Invalid

如果您对私有属性背后的更多细节/决策感兴趣,那么这里有一篇 很好的文章

目前 有一个 PR 将私有属性添加到 Babel ,以便您可以在应用中使用它们。

原文链接:https://tylermcginnis.com/javascript-private-and-public-class-fields/

发表评论

登录后才能评论