设计模式给我们的，不仅仅是一些问题的解决方案，更有追求完美“理型”的渴望。——《重构》译者熊节
2 年前作为一个前端菜鸟，初次接触设计模式，对其作用的描述比较笼统。今天再来更新下我对它的看法。
🪄 设计模式到底是什么
Dan 说，开发者之间有着一些“共同语言”，来作为传递理念的基础。设计模式就是这些“语言”其中之一。
（以下简称设计模式为 DP）
DP 基于 OO（源自 Java）的经验浓缩的模型，用于开发可维护和扩展的设计。但是其出发点也决定了其终点：
- 本质是 SOLID 原则中，某项原则的强化，或者几项组合后，得到的代码形式。
- 它比抽象稍微高一层。
- 基于 OO，回到 OO。脱离 OO 也能应用，但是要真正地理解其原理。
- 有理论认为，DP 是语言缺陷的补丁
- 颗粒度较小，只能用于承载纯粹的设计。要容纳业务（比如浏览器事件模型）则需要上升到框架。
40 年中都被奉为软件世界的真理，支撑起了全世界各个行业大大小小的业务。设计模式绝对算得上 CS 中的牛顿定理。我们学习这些抽象，也是设计更大的系统的基石。比如 Vue、Axios 的源码基本就是 DP 的组合或者变种。没人能仅靠底层语法完成优秀设计的。
不少自学程序员认为，设计模式属于“花里胡哨的技巧”，因为它不像算法解决实际问题。
🤔️ DP 解决实际问题吗？
我们就要定义一下，什么是“实际问题”了。回想一下，算法的特性是高效（时间、空间）解决问题，不然堆一坨 for 完成搜索算法，我们 Google 一个词条都要花上一天。同样的，暴力堆代码也照样能完成功能，不过维护性就让其他人头痛。会想一下，有多少次我们被层层堆叠的 if..else 绕到头晕目眩。
反思一下我们的工作：80% 的时候，都是在维护，而不是开发新功能。DP 针对维护性和扩展性，恰好就是解决这 80% 场景下的问题。
所以，DP 解决的是设计和合作的问题。
不愿意学习 DP 的人，暴露了两个弱点：
- 不接触复杂设计，不关注优秀开源项目，满足于低级堆砌代码的业务
- 工作不需要合作，或者合作能力低下，编码只考虑自己
复杂的软件必须有清晰合理的架构，否则无法开发和维护。假如你的工作中一直用不到 DP 或者其它难度稍高的概念，我觉得应该是时候反思一下，这份工作是否能带来足够的成长。
🌛 总结，与下一步
DP 为代码设计注入了生命力，使项目能够长久、稳定地发展。它也是我们进入更大的世界的敲门砖。
但也有人指出，前期就使用 DP，容易导致“过度工程”，而忽略了实用性——这个代码最应该关注的特性。
《重构》一书的核心，就是实用性。我将继续尝试从中找到更深层的答案。