如何写出好的 JavaScript —— 浅谈 API 设计

这是 奇舞前端特训营 JavaScript 培训课程 的节选。很多同学觉得写 JavaScript 很简单,只要能写出功能来,效果能实现就好。还有一些培训机构,专门教人写各种“炫酷特效”,以此让许多人觉得这些培训很“牛逼”。然而事实上,能写 JavaScript 和写好 JavaScript 这中间还有很遥远的距离。成为专业前端,注定在 JavaScript 路途上需要一步步扎实的修炼,没有捷径。

t0111abe7db051d82e7

看一个简单的例子:

实现一个类似于“交通灯”的效果,让三个不同颜色的圆点每隔 2 秒循环切换。

对应的 HTML 和 CSS 如下:

那么这一功能的 JavaScript 该如何实现呢?

版本一

有的同学说,这个实现还不简单嘛?直接用几个定时器一下切换不就好了:

没错,就这个功能本身,这样实现就 OK 了。但是这样实现有什么问题呢?

首先是过程耦合,状态切换是wait->stop->pass 循环,在上面的设计里,实际上操作顺序是耦合在一起的,要先 ‘wait’,然后等待 2000 毫秒再 ‘stop’,然后再等待 2000 毫秒在 ‘pass’,这中间的顺序一旦有调整,需求有变化,代码都需要修改。

其次,这样的异步嵌套是会产生 callback hell 的,如果需求不是三盏灯,而是五盏灯、十盏灯,代码的嵌套结构就很深,看起来就很难看了。

所以我们说,版本一方法虽然直接,但因为抽象程度很低(几乎没有提供任何抽象 API),它的扩展性很不好,因为异步问题没处理,代码结构也很不好。如果只能写这样的代码,是不能说就写好了 JavaScript 的。

版本二

要解决版本一的过程耦合问题,最简单的思路是将状态['wait','stop','pass']抽象出来:

这是一种数据抽象的思路,应用它我们得到了上面的这个版本。

这一版本比前一版本要好很多,但是它也有问题,最大的问题就是封装性很差,它把 stateList 和 currentStateIndex 都暴露出来了,而且以全局变量的形式,这么做很不好,需要优化。

版本三

版本三是中规中矩的一版,也是一般我们在工作中比较常用的思路。应该将暴露出来的 API 暴露出来(本例中的 stateList)。将不应该暴露出来的数据或状态隐藏(本例中的 currentStateIndex)。

有许多同学觉得说写出这一版本来已经很不错的。的确,应该也还不错,但这一版的抽象程度其实也不是很高,或者说,如果考虑适用性,这版已经很好了,但是如果考虑可复用性的话,这版依然有改进空间。

我们再看一个思路上较有意思的版本。

版本四

这一版用的是过程抽象的思路,而过程抽象,是函数式编程的基础。在这里,我们抽象出了一个 poll(...fnList) 的高阶组合函数,它将一个函数列表组合起来,每次调用时依次轮流执行列表里的函数。

我们说,程序设计的本质是抽象,而过程抽象是一种与数据抽象对应的思路,它们是两种不同的抽象模型。数据抽象比较基础,而过程抽象相对高级一些,也更灵活一些。数据抽象是研究函数如何操作数据,而过程抽象则在此基础上研究函数如何操作函数。所以说如果把抽象比作数学,那么数据抽象是初等数学,过程抽象则是高等数学。同一个问题,既可以用初等数学来解决,又可以用高等数学来解决。用什么方法解决,取决于问题的模型和难度等等。


好了,上面我们有了四个版本,那么是否考虑了这些版本就足够了呢?

并不是。因为需求是会变更的。假设现在需求变化了:

需求变更:让 wait、stop、pass 状态的持续时长不相等,分别改成 1秒、2秒、3秒。

t018c41be76ca3460a2

那么,我们发现 ——

除了版本一之外,版本二、三、四全都跪了……

t01b151b19a590ffa89

那是否意味着我们要回归到版本一呢?

当然并不是。


版本五

版本五的思路是,既然我们需要考虑不同的持续时间,那么我们需要将等待时间抽象出来

这一版本里我们用了 Promise 来处理回调问题,当然对 ES6 之前的版本,可以用 shim 或 polyfill、第三方库,也可以选择不用 Promise。

版本五抽象出的 wait 方法也还比较通用,可以用在其他地方。这是版本五好的一点。

版本六

我们还可以进一步抽象,设计出版本六,或者类似的对象模型

这一版本里,我们设计了一个 TrafficProtocol 类,它有 putState、reset、start 三个方法:

  • putState 接受一个函数作为参数,这个函数自身有两个参数,一个是 subject,是由 TrafficProtocol 对象初始化时设定的 DOM 元素,一个是 next,是一个函数,表示结束当前 state,进入下一个 state。
  • reset 结束当前状态循环,开始新的循环。
  • start 开始执行循环,这里的实现是直接调用 reset。

看一下 reset 的实现思路:

在这里我们创建一个 statePromise,然后将 stateList 中的方法(通过 putState 添加的)依次绑定到 promise 上。如果设置了 autoReset,那么我们在 promise 的最后绑定 reset 自身,这样就实现了循环切换。

有了这个模型,我们要添加新的状态,只需要通过 putState 添加一个新的状态就好了。这一模型不仅仅可以用在这个需求里,还可以用在任何需要顺序执行异步请求的地方。

最后,我们看到,版本六用到了面向对象、过程抽象、Promise等模式,它的优点是 API 设计灵活,通用性和扩展性好。但是版本六也有缺点,它的实现复杂度比前面的几个版本都高,我们在做这样的设计时,也需要考虑是否有过度设计的嫌疑。

总结

  • 设计是把双刃剑,繁简需要权衡,尺度需要把握。
  • 写代码简单,程序设计不易,需要走心。
2 10 收藏 3 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 除了123看懂外,后面的就。。。  道路漫长啊!

  • PunCha 程序员 01/06

    看了你的代码,我觉得很烂!作者其实对抽象和函数式编程其实一直半解。基于此,写出了自认为“优雅”的代码,其实就是一坨屎。这种代码可读性低、维护成本高、出错概率大!

    就用版本六来说吧,假如我不看代码,只看你的API,你提供了一个交通灯协议(TrafficProtocol)的类和三个API:开始(start),添加状态(pushState),重置状态(reset)。什么意思?我一头雾水,有start没有stop?有添加状态没有移除状态?状态重置是什么意思?这和交通等协议有什么关系?

    那么只有看代码了:

    pushState()传入的state并非是状态,而是一个方法,需要实现2点:状态的变化,于延迟。好了,你把抽象细节完全暴露给用户了。
    reset():其实不是重置状态,而是重新开始。那么叫restart()比较合适吧。
    没有提供stop()是因为要实现stop功能,成本高。

    好了,读了代码,发现这个交通灯协议类什么都没做,其真正的功能就是把回调函数诶个调用下,调用完了再从头开始循环调用。和交通有什么关系?和协议有什么关系?

    你给了例子回答了一切,要使用这屎一样的抽象与封装,客户端需要15行代码。15行!例子三加起来也没有15行!你想过客户端的心情吗?用了你的封装,代码一行没省,而且不看你的实现,根本读不懂在干什么。

    最后,我想问个问题,你说你的设计是为了将来需求的变更,那么我有2个比较合理的需求:1)我想知道当前的交通灯状态getCurrentState(),2)我想暂停交通灯服务。那么,要实现这两个功能,我要修改多少代码?

跳到底部
返回顶部