关于设计模式:代码设计再看设计模式

2 年前作为一个前端菜鸟，首次接触设计模式，立刻上比拟抽象。明天再来更新下我对它的认识。

🪄 设计模式也是魔法的一种

Dan 说，开发者之间有着一些“共同语言”，来作为传递理念的根底。设计模式就是这些“语言”其中之一。
（以下简称设计模式为 DP）

DP 基于 OO（源自 Java）的教训稀释的模型，用于开发可保护和扩大的设计。然而其出发点也决定了其起点：

1. 实质是 SOLID 准则中，某项准则的强化，或者几项组合后，失去的代码模式。
2. 它比形象略微高一层。
3. 基于 OO，回到 OO。脱离 OO 也能利用，然而要真正地了解其原理。
4. 有实践认为，DP 是语言缺点的补丁
5. 颗粒度较小，只能用于承载纯正的设计。要包容业务（比方浏览器事件模型）则须要回升到框架。

40 年中都被奉为软件世界的真谛，撑持起了全世界各个行业大大小小的业务。设计模式相对算得上 CS 中的牛顿定理。咱们学习这些形象，也是设计更大的零碎的基石。比方 Vue、Axios 的源码根本就是 DP 的组合或者变种。没人能仅靠底层语法实现优良设计的。
不少自学程序员认为，设计模式属于“花里胡哨的技巧”，因为它不像算法解决理论问题。

🤔️ 那什么才算理论问题？

咱们就要定义一下，什么是“理论问题”了。回忆一下，算法的个性是高效（工夫、空间）解决问题，不然堆一坨 for 实现搜索算法，咱们 Google 一个词条都要花上一天。同样的，暴力堆代码也照样能实现性能，不过维护性就让其他人头痛。会想一下，有多少次咱们被层层重叠的 if..else 绕到头晕目眩。
反思一下咱们的工作：80% 的时候，都是在保护，而不是开发新性能。DP 针对维护性和扩展性，恰好就是解决这 80% 场景下的问题。
所以，DP 解决的是设计和单干的问题。
放弃学习 DP 的人，裸露了两个弱点：

1. 不接触简单设计，满足于低级堆砌代码的业务
2. 工作不须要单干，或者单干能力低下，编码只思考本人

简单的软件必须有清晰正当的架构，否则无奈开发和保护。如果你的工作中始终用不到 DP 或者其它难度稍高的概念，我感觉应该是时候反思一下，这份工作是否能带来足够的成长。