前言
# 前言
# 一、什么是设计模式
一个模式就是一个可重用的方案，模式的另一种解释就是一个我们如何解决问题的模板
设计模式是代码设计经验的总结，为了可重用代码，保证代码的可靠性等。
设计模式有以下三点好处：
- 模式是行之有效的解决方法
- 模式可以很容易地重用
- 模式善于表达
# 二、反模式
如果我们认为一种模式代表一种最佳实践，那么一种反模式就代表我们已经学到的教训
反模式这个术语是1995年由安德鲁·凯尼格在当年的11月C++报告中创造的，是受“四人组”所著《设计模式》一书的启发。在凯尼格的报告中，他提出反模式的两个概念：
- 描述对于一个特殊的问题，提出了一个糟糕的解决方案，最终导致一个坏结果发生
- 描述如何摆脱上述解决方案并能提出一个好的解决方案
# 2.1 反模式的由来
每一个设计问题都是以在两个实体之间实现平衡为开始的，即：问题的形式和它的上下文。形式是解决问题的方案；上下文定义该问题。
虽然设计模式很重要，但是理解反模式也同样重要。创建应用程序时，一个项目的声明周期就会以此为起点；一旦完成了初始版本，就需要进行维护。最终方案的质量好坏取决于技能水平和团队投入时间。
当然这里的好坏是在上下文中考虑的，如果一个“完美的”设计模式应用于错误的上下文中，那么它也可能是一个反模式。应用程序在进入生产环境并即将进入维护模式时会面临更大的挑战。之前没有研究过该应用程序的开发人员，在这样的系统上工作，可能会将不良设计意外地引入到项目中，如果说将不良实践创建为反模式，则能让开发人员有办法提前识别这些反模式，这样可以避免常见错误的发生。
# 2.2 Javascript中常见的反模式有很多，简单举几个例子：
- 在全局上下文中定义大量的变量污染全局命名空间。
- 向setTimeout或setInterval传递字符串，无意中触发eval( )的内部使用。
- 修改Object类的原型（这是一个特别不良的反模式）
- 以内联形式使用Javascript，它是不可改变的。
- 在使用document.createElement等原生DOM方法更适合的情况下使用document.write。多年来document.write一直都在被滥用，并有相当多的缺点，包括：如果在页面加载完成后执行document.write，它实际上会重写我们的页面，而documet.createElement则不会。
# 三、 设计模式的种类
设计模式主要分为三大类型，创建型模式，结构型模式和行为型模式
# 3.1 创建型模式
创建型设计模式关注于对象创建的机制方法，通过该方法，对象以适应工作环境的方式被创建
基本的对象创建方法可能会给项目增加额外的复杂性，而这些模式的目的就是为了通过控制创建过程解决这个问题，解决对象创建方法额外复杂性
在该分类下的模式有：
- 构造器模式（Constructor）：被用来创建特殊类型的对象
- 工厂模式（Factory）：通过将数据和事件接口化来构建若干个子类
- 抽象工厂模式 （Abstract）：建立若干族类的一个实例，这个实例不需要具体类的细节信息。（抽象类）
- 原型模式 （Prototype）：一个完全初始化的实例，用于拷贝或者克隆
- 单例模式 （Singleton）：一个类只有唯一的一个实例，这个实例在整个程序中有一个全局的访问点
- 建造者模式（Builder）：将对象的构建方法和其表现形式分离开来，总是构建相同类型的对象
# 3.2 结构设计模式
结构模式关注于对象组成和通常识别的方式实现不同对象之间的关系。该模式有助于在系统的某一部分发生改变的时候，整个系统结构不需要改变。该模式同样有助于对系统中某部分没有达到某一目的的部分进行重组。
在该分类下的模式有：
- 装饰模式（Decorator）：动态给对象增加一些可替换的处理流程。
- 外观模式（Facada）：一个类隐藏了内部子系统的复杂度，只暴露出一些简单的接口。
- 享元模式（Flyweight）：一个细粒度对象，用于将包含在其它地方的信息 在不同对象之间高效地共享。
- 适配器模式（Adapter）：将不同类的接口进行匹配，调整，这样尽管内部接口不兼容但是不同的类还是可以协同工作的。
- 代理模式（Proxy）：一个充当占位符的对象用来代表一个真实的对象
# 3.3 行为设计模式
行为模式关注改善或精简在系统中不同对象间通信。
在该分类下的模式有：
- 迭代模式（Iterator）：在不需要直到集合内部工作原理的情况下，顺序访问一个集合里面的元素。
- 中介者模式（Mediator）：在类之间定义简化的通信方式，用于避免类之间显式的持有彼此的引用。
- 观察者模式（Observer）：用于将变化通知给多个类的方式，可以保证类之间的一致性。
- 访问者模式（Visitor）：为类增加新的操作而不改变类本身