class 要使用私有变量，居然要包一层闭包，再用一个 WeakMap 去存

因为 ECMAScript 从来就没有私有成员这种概念，而闭包是确保变量不会泄漏的可靠方法，所以用闭包模拟私有成员是 JavaScript 的必修课。至于 WeakMap 来存并非是唯一的方案（不过的确是比较好的），比方说 Symbols 也可以（参见：http://exploringjs.com/es6/ch_classes.html#sec_private-data-for-classes）。

问题是连实例变量都没有，这个 class 究竟有什么用？

Are you sure?

class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }
}

要类变量的话也是妥妥要包一层了

Again, Are you sure?

class Point {
    constructor(x, y) {
        this.x = x;
        this.y = y;
    }
    static get ZERO() {
        return new Point(0, 0);
    }
}

或者直接 Point.ZERO = new Point(0, 0) 也是可以的。

还不如直接用构造函数呢

你想多了，其实 class 就是构造器＋原型继承的语法糖而已，JavaScript 从来都不是基于类型系统的 OO 编程语言，这一点一直都没有变过。

---

我不喜欢用 Class，不管是过去的构造器模式还是现在的新语法。不是因为对任何编程范式有偏见，本来 JavaScript 就不是 Class Based OO 语言，硬生生的去模仿就是会觉得别扭罢了。和 Java、C# 等语言不同，class 不是必需品，这也就意味着你完全可以不用。然而奇怪的是使用 JavaScript 的人很多却是不用 class 不行，这是不是对这门语言存在很大的误解呢？

更重要的是在实践中我们会发现使用其他的模式——比如工厂函数（Factory Functions）要远比 class 简洁、灵活，用它来替代 class 几乎总能得到更好的结果。

简单工厂函数

// person.js
export default _ => {
  return {
    greet() {
      console.log('Hello world!')
    }
  }
}

用起来和一个 Class 几乎一模一样——除了不需要用 new，这不算坏处吧？

import Person from './person'

const nightire = Person()
nightire.greet()  // "Hello world!"

依赖注入

console.log 限制了 greet 方法的行为，为了不局限问候的方式，可以使用依赖注入——这是解耦的一种简便易行的方法。即使在现实中很多时候看不出需要依赖注入的迹象，我们也应该有意识的这么做。在定义一种“类型”的时候对外界知道的越少越好（于是就更容易复用、扩展、组合……）。

// person.js
export default ioStream => {
  return {
    greet() {
      ioStream.send('Hello world!')
    }
  }
}

比如说我们可以把 console 封装一下，让系统内所有的 ioStream 都具有统一的接口，然后就可以直接使用：

import Person from './person'
import ConsoleStream from 'console-stream'

const nightire = Person(ConsoleStream())
nightire.greet()  // "Hello world!"

不用 Mocking 的单元测试

这个是顺带一提的事情，因为我注意到不懂得处理依赖注入（或者说更高层次上的解耦概念）的人通常都会把单元测试写得无比蛋疼……实际上，对象字面量在很多时候胜过一切构造模式：

import test from 'ava'
import Person from './person'

test(`a person can send message to io stream`, t => {
  const ioStream = {
    send(anything) {
      t.same(anything, 'Hello world!');
    }
  }

  const anyone = Person(ioStream)
  anyone.greet()
})

封装

其实私有成员可以变得很自然很自然，闭包一样在用，只是不那么扎眼了：

// person.js
export default ioStream => {
  let _message = 'Hello world!'

  return {
    greet() {
      ioStream.send('Hello world!')
    },

    get message() {
      return _message
    },

    set message(message) {
      _message = message
    }
  }
}

用法就不写了，和之前没什么区别。getter/setter 也不是必须的，看接口设计需求了。

组合

这才是对 OO 来说最重要的（相较于怎么定义／创建对象来说），总的来说组合总是要优于继承，工厂模式搞起来尤其轻松。

比方说我们已经有了一个动作“类”：

// action.js
export default ioStream => {
  return {
    wave() {
      ioStream.send('(Waving Hands...)')
    }
  }
}

那么与 Person 的组合可以这样：

import Person from './person'
import Action from './action'
import ConsoleStream from 'console-stream'

const _console = ConsoleStream()
const nightire = Object.assign({}, Person(_console), Action(_console))

nightire.message = 'Farewell, my friend!'
nightire.wave()  // "(Waving Hands...)"
nightire.greet()  // "Farewell, my friend!"

事前绑定的方法引用

这是我觉得最好的一个优点。由于 this 在 JavaScript 中是在运行时动态绑定的，如果使用你代码的人不理解这一点，那么他们就会犯错误（而且会指责是你写的不对……）。有些人是因为不理解 this 而不敢用，有些人则是为了迁就前者而干脆不去用，架构师会比较容易体会这类情况。

这是典型的容易犯错的例子：

// stepper.js
export default class Stepper {
  constructor(offset) {
    this.offset = offset
  }

  add(amount) {
    return amount + this.offset
  }
}

// main.js
import Stepper from './stepper'

const stepper = new Stepper(1)
[1, 2, 3].map(stepper.add.bind(stepper))

容易犯错的地方就是最后一行，如果不加 .bind(stepper) 的话最终 this 的指向就是错误的。但往往使用者并不理解这一点，反正看到你的文档就知道这个能加上初始化传入的 offset 就是了，除非你不厌其烦的在文档里强调：“注意上下文的变化，如有必要请用 bind() 明确 this 的指向“……啊，说不定你还得培训一下让大家都知道如有“必要”的确切范围。

然而你也可以这样来重写一下：

// stepper.js
export default offset => {
  return {
    add(amount) {
      return amount + offset
    }
  }
}

// main.js
import Stepper from './stepper'

const stepper = Stepper(1)
[1, 2, 3].map(stepper.add)  // [2, 3, 4]

于是无论是具体实现还是接口定义都能保持简洁一致。

---

这是一些使用工厂函数代替类型定义的常用场景，我不是说百分之百不要用 class（或是构造器之类的），他们也有用武之地，只是人们在抱怨他们不如熟悉的 Java 等语言好用的时候也应该问问自己：我真的了解它吗？这是唯一的选择吗？