“橘生淮南则为橘,橘生淮北则为枳”——一些在服务端应用场景下看似合理、好用又酷炫的操作，生搬硬套到前端的场景里可能就会弄巧成拙。本册的目的并不是做传统设计模式书籍的“译本”，而是面向前端工程师，讲有利于前端的技术。因此在正式的实战章节里，我们权衡每种模式对前端的价值、对 23 种设计模式做了取舍，保留下来的这些设计模式，具备这两个共性：
- 前端能用，而且好用；
- 面试会考，而且常考。
通过学习这部分设计模式，我们至少可以达到三个目的：
- 充分理解前端设计模式的核心思想和基本理念，在具体的场景中掌握抽象的设计原则
- 会写代码，会写好代码；
- 会面试，能言之有物。
其实不难
设计模式的“难”，在于其令人望而生畏的抽象性和知识点的分散性。这带来了本册要着重解决的问题——帮助大家摆脱枯燥乏味的技术恐惧感。
抽象性几乎是所有理论性知识共有的特性，它带来最直观的问题就是可能一段话你每个字都认识，但连在一起不知道它在说啥：）。于是产生了“这块知识看起来好牛逼，我一定学不会吧”这样的错觉。
其实设计模式并不高大上，它是一个非常接地气、非常实际的东西——因为它本身就是一帮非常苦逼的程序员在自己的职业生涯里实打实地踩坑踩出来的。解决知识抽象性带来的理解障碍，重要的不是反复的陈述、解释，而是把自己放到一个正确的场景里，去体会这个模式的好。在学习具体设计模式的过程中，我们每个章节都以原理->实践->总结这样的流程来走，也希望大家不要随意跳读，确保自己不仅是跟着看了，更是跟着做了。设计模式说起来是理论知识，但它毕竟是人们在实践过程中总结、提炼出来的，掌握它的意义，正是为了把它还原到我们日常的实践中去。
分散性则是因为设计模式本身就是一套解决不同问题的方案的集合，这些方案之间乍一看好像没有什么关联，故而很容易使学习者陷入边学边忘的窘境。
但所谓“分散性”其实也是纸老虎——深入了解设计模式后，大家会发现模式与模式间存在着不可忽略的共性与关联——在下一小节《设计模式的道与术》中，我们将会学习设计模式中几个重要的设计原则和核心的设计思想；接下来学习具体的设计模式时，小册会在具体的应用场景里把这些设计原则掰碎嚼烂了还原给大家。在这个过程中大家会发现，不同的设计模式并非是一座座的孤岛，他们之间彼此呼应、相互成就，共同构建起了一套完整而经典的软件思想体系。
此外，设计模式中有几个特别重要、特别好使、特别受面试官关注的的！
前端工程师，首先是软件工程师
过去，人们对软件工程的理解比较狭隘，认为前端就是页面，和软件是两回事儿。随着前端应用复杂度的日新月异，如今的前端应用也妥妥地成为了软件思想的一种载体，而前端工程师，也被要求在掌握多重专业技能之余，具备最基本的软件理论知识。
技术人之间的口水战，每次但凡想上升一点高度，便要拿”架构“这样高大上的话题出来晃晃眼。但事实上，很多人缺乏的并不是这种高瞻远瞩的激情，而是我们前面提到的“不变能力”中最基本的那一点——用健壮的代码去解决具体的问题的能力。这个能力在软件工程领域所对标的经典知识体系，恰恰就是设计模式。
所以说，想做靠谱开发，先掌握设计模式。
结尾：
基础理论知识是一个人的基线，理论越强基线越高。再为自己定一个目标和向上攀附的阶梯，那么达到目标就是时间问题，而很多野路子工程师搞了半辈子也未达到优秀工程师的基线，很多他们绞尽脑汁得出的高深学问，不过是正规工程师看起来很自然的东西。—— 吴军
