回调地狱
但实际上回调地狱与嵌套和缩进几乎没有什么关系。它引起的问题要比这些严重得多。
还有一点需要注意:要把步骤 2、步骤 3 和步骤 4 连接在一起让它们顺序执行,只用回调的话,代价可以接受的唯一方式是把步骤 2 硬编码到步骤 1 中,步骤 3 硬编码到步骤 2中,步骤 4 硬编码到步骤 3 中,以此类推。如果实际上步骤 2 总会引出步骤 3 是一个固定条件的话,硬编码本身倒不一定是坏事。
但是,硬编码肯定会使代码更脆弱一些,因为它并没有考虑可能导致步骤执行顺序偏离的异常情况。比如,如果步骤 2 失败,就永远不会到达步骤 3,不管是重试步骤 2,还是跳转到其他错误处理流程,等等。
举例来说,为了更优雅地处理错误,有些 API 设计提供了分离回调(一个用于成功通知,
一个用于出错通知)
还有一种常见的回调模式叫作“error-first 风格”(有时候也称为“Node 风格”,因为几乎
所有 Node.js API 都采用这种风格),其中回调的第一个参数保留用作错误对象(如果有的话)。如果成功的话,这个参数就会被清空 / 置假(后续的参数就是成功数据)。
我们把这称为控制反转(inversion of control),也就是把自己程序一部分的执行控制交给某个第三方。在你的代码和第三方工具(一组你希望有人维护的东西)之间有一份并没有明确表达的契约。
网友评论