共计 838 个字符，预计需要花费 3 分钟才能阅读完成。
2 年前作为一个前端菜鸟，首次接触设计模式，立刻上比拟抽象。明天再来更新下我对它的认识。
🪄 设计模式也是魔法的一种
Dan 说，开发者之间有着一些“共同语言”，来作为传递理念的根底。设计模式就是这些“语言”其中之一。
（以下简称设计模式为 DP）
DP 基于 OO（源自 Java）的教训稀释的模型，用于开发可保护和扩大的设计。然而其出发点也决定了其起点：
- 实质是 SOLID 准则中，某项准则的强化，或者几项组合后，失去的代码模式。
- 它比形象略微高一层。
- 基于 OO，回到 OO。脱离 OO 也能利用，然而要真正地了解其原理。
- 有实践认为，DP 是语言缺点的补丁
- 颗粒度较小，只能用于承载纯正的设计。要包容业务（比方浏览器事件模型）则须要回升到框架。
40 年中都被奉为软件世界的真谛，撑持起了全世界各个行业大大小小的业务。设计模式相对算得上 CS 中的牛顿定理。咱们学习这些形象，也是设计更大的零碎的基石。比方 Vue、Axios 的源码根本就是 DP 的组合或者变种。没人能仅靠底层语法实现优良设计的。
不少自学程序员认为，设计模式属于“花里胡哨的技巧”，因为它不像算法解决理论问题。
🤔️ 那什么才算理论问题？
咱们就要定义一下，什么是“理论问题”了。回忆一下，算法的个性是高效（工夫、空间）解决问题，不然堆一坨 for 实现搜索算法，咱们 Google 一个词条都要花上一天。同样的，暴力堆代码也照样能实现性能，不过维护性就让其他人头痛。会想一下，有多少次咱们被层层重叠的 if..else 绕到头晕目眩。
反思一下咱们的工作：80% 的时候，都是在保护，而不是开发新性能。DP 针对维护性和扩展性，恰好就是解决这 80% 场景下的问题。
所以，DP 解决的是设计和单干的问题。
放弃学习 DP 的人，裸露了两个弱点：
- 不接触简单设计，满足于低级堆砌代码的业务
- 工作不须要单干，或者单干能力低下，编码只思考本人
简单的软件必须有清晰正当的架构，否则无奈开发和保护。如果你的工作中始终用不到 DP 或者其它难度稍高的概念，我感觉应该是时候反思一下，这份工作是否能带来足够的成长。
正文完
