当设计模式遇上 Hooks

简介： 数据结构与设计模式能够指导我们在开发复杂系统中寻得一条清晰的道路，既然都说 Hooks 难以维护，那就尝试让「神」来拯救这混乱的局面。对于「设计模式是否有助于我们写出更优雅的 Hooks 」这个问题，看完本文，相信你心中也会有自己的答案。

作者 | 阿晨
来源 | 阿里技术公众号

一 前言

「设计模式」是一个老生常谈的话题，但更多是集中在面向对象语言领域，如 C++，Java 等。前端领域对于设计模式的探讨热度并不是很高，很多人觉得对于 JavaScript 这种典型的面向过程的语言来说，设计模式的价值很难体现。之前我持有类似的观点，对于设计模式的理解仅停留在概念层面，没有深入去了解其在前端工程中的实践。近期阅读了《 JavaScript 设计模式与开发实践》一书，书中介绍了 15 种常见设计模式和基本的设计原则，以及如何使用 JavaScript 优雅实现并应用于实际工程中。碰巧前不久团队举行了一场关于 Hooks 的辩论赛，而 Hooks 的核心思想在于函数式编程，于是决定探究一下「设计模式是否有助于我们写出更优雅的 Hooks 」这一话题。

二 为什么是设计模式

在逆袭武侠剧中，主人公向第一位师父请教武艺时，最开始老师父只会让主人公挑水、扎马步等基本功，主人公这时总是会诸般抱怨，但又由于某些客观原因又不得不坚持，之后开始学习真正的武艺时才顿悟之前老师父的一番苦心，夯实基础后学习武艺突飞猛进，最终成为一代大侠。对于我们开发者来说，「数据结构」和「设计模式」就是老师父所教的基本功，它不一定能够让我们走得更快，但一定可以让我们走得更稳、更远，有助于我们写出高可靠且易于维护的代码，避免日后被 “挖坟”。

在 Hooks 发布以来，饱受诟病的一点就是维护成本激增，特别是对于成员能力水平差距较大的团队来说。即便一开始由经验老到的同学搭建整个项目框架，一旦交由新人维护一段时间后，大概率也会变得面目全非，更不用说让新人使用 Hooks 开发从零到一的工程。我理解这是由于 Hooks 的高度灵活性所导致的，Class Component 尚有一系列生命周期方法来约束，而 Hooks 除了 API 参数上的约束，也仅有 “只在最顶层使用 Hook” “只在 React 函数中调用 Hook” 两条强制规则。另一方面自定义 Hook 提高组件逻辑复用率的同时，也导致经验不足的开发者在抽象时缺少设计。Class Component 中对于逻辑的抽象通常会抽象为纯函数，而 Hooks 的封装则可能携带各种副作用（useEffect），出现 bug 时排查成本较大。

那么既然「设计模式」是一种基本功，而「Hooks」是一种新招式，那我们就尝试从设计模式出发，攻克新招式。

三 有哪些经典的设计模式

在正式进入话题之前，我们先简单回顾一下那些快被我们遗忘的经典设计模式和设计原则。日常中，我们提到设计原则都会将其简化为「SOLID」，对应于单一职责原则（Single Responsibility Principle）、开放/封闭原则（Open Closed Principle）、里氏替代原则（Liskov Substitution Principle）、最小知道原则（Law of Demeter）、接口隔离