前言

有些程序员把设计模式视为圣经，唯模式至上； 有些人却认为设计模式只在 C++ 或者 Java 中有用武之地，JavaScript 这种动态语言根本就没有设计模式一说。

设计模式的定义是：在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案。

通俗一点说，设计模式是在某种场合下对某个问题的一种解决方案。

人类可以走到生物链顶端的前两个原因分别是会 “使用名字” 和 “使用工具”。

这个问题发生的场景似曾相识，以前我遇到并解决过这个问题，但是我不知道怎么跟别人去描述它。 我们非常希望给这个问题出现的场景和解决方案取一个统一的名字，当别人听到这个名字的时候，便知道我想表达什么。

each 函数其实就是迭代器模式。

小说家很少从头开始设计剧情，足球教练也很少从头开始发明战术，他们总是沿袭一些已经存在的模式。 同样，在软件设计中，模式是一些经过了大量实际项目验证的优秀解决方案。 熟悉这些模式的程序员，对某些模式的理解也许形成了条件反射。 当合适的场景出现时，他们可以很快地找到某种模式作为解决方案。

当他们看到系统中存在一些大量的相似对象，这些对象给系统的内存带来了较大的负担。 如果他们熟悉享元模式，那么第一时间就可以想到用享元模式来优化这个系统。

享元模式。（享元：共享的单元） 享元模式通过复用对象，以达到节省内存的目的。 主要用于解决在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来。 如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。 当他们看到系统中存在一些大量的相似对象，这些对象给系统的内存带来了较大的负担。 如果他们熟悉享元模式，那么第一时间就可以想到用享元模式来优化这个系统。

系统中某个接口的结构已经不能符合目前的需求，但他们又不想去改动这个被灰尘遮住的老接口，一个熟悉模式的程序员将很快地找到适配器模式来解决这个问题。

《设计模式》这本书完全是从面向对象设计的角度出发的，通过对封装、继承、多态、组合等技术的反复使用，提炼出一些可重复使用的面向对象设计技巧。

《设计模式》最初讲的确实是静态类型语言中的设计模式，原书大部分代码由 C++ 写成。

所有设计模式的实现都遵循一条原则，即 “找出程序中变化的地方，并将变化封装起来”。

一个程序的设计总是可以分为可变的部分和不变的部分。 当我们找出可变的部分，并且把这些部分封装起来，那么剩下的就是不变和稳定的部分。 这些不变和稳定的部分是非常容易复用的。 这也是设计模式为什么描写的是可复用面向对象软件基础的原因。

设计模式被人误解的一个重要原因是人们对它的误用和滥用，比如将一些模式用在了错误的场景中，或者说在不该使用模式的地方刻意使用模式。 特别是初学者在刚学会使用一个模式时，恨不得把所有的代码都用这个模式来实现。

当我们有了一把锤子，看什么都是钉子。

哪些才算正确的地方，只有在我们深刻理解了模式的意图之后，再结合项目的实际场景才会知道。

分辨模式的关键是意图而不是结构。

有很多模式的类图和结构确实很相似，但这不太重要，辨别模式的关键是这个模式出现的场景，以及为我们解决了什么问题。

JavaScript 实际上是不需要工厂方法模式的。

模式的社区一直在发展。 GoF 在 1995 年提出了 23 种设计模式。 但模式不仅仅局限于这 23 种。 在近 20 年的时间里，也许有更多的模式已经被人发现并总结了出来。 比如一些 JavaScript 图书中会提到模块模式、沙箱模式等。