责任链模式
责任链模式为请求创建了一个
接收者对象的链
。这种模式给予请求的类型，对发送者和接收者进行解耦。
关键代码：
Handler 里面聚合它自己，在 HanleRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。
应用实例：
1、
JS 中的事件冒泡
。 2、JAVA WEB 中 Apache Tomcat 对
Encoding 的处理
，3.Struts2 的拦截器，4.
jsp servlet 的 Filter.
优点：
1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。
缺点：
1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。
使用场景：
1、有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。 2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 3、可动态指定一组对象处理请求。
命令模式
命令模式是一种数据驱动的设计模式,
请求以命令的形式包裹在对象中
，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。
应用实例：
struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。
优点：
1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。
缺点：
使用命令模式可能会导致某些系统有过多的具体命令类。
使用场景：
认为是命令的地方都可以使用命令模式，比如： 1、GUI 中每一个按钮都是一条命令。 2、模拟 CMD。
解释器模式(少见)
提供了评估语言的语法或表达式的方式， 给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子
关键代码：
构件环境类，包含解释器之外的一些全局信息，一般是 HashMap。
应用实例：
编译器、运算表达式计算。
优点：
1、可扩展性比较好，灵活。 2、增加了新的解释表达式的方式。 3、易于实现简单文法。
缺点：
1、可利用场景比较少。 2、对于复杂的文法比较难维护。 3、解释器模式会引起类膨胀。 4、解释器模式采用递归调用方法。
迭代器模式
这种模式用于顺序访问集合对象的元素，不需要知道集合对象的底层表示。
关键代码：
定义接口：hasNext, next。
应用实例：
JAVA 中的 iterator。
优点：
1、它支持以不同的方式遍历一个聚合对象。 2、迭代器简化了聚合类。 3、在同一个聚合上可以有多个遍历。 4、在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。
缺点：
由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
中介者模式
这种模式提供了一个中介类
，
该类通常处理不同类之间的通信
(
用来降低多个对象和类之间的通信复杂性。)
应用实例：
MVC 框架，其中C（控制器）就是 M（模型）和 V（视图）的中介者。
优点：
1、降低了类的复杂度，将一对多转化成了一对一。 2、各个类之间的解耦。 3、符合迪米特原则。
缺点：
中介者会庞大，变得复杂难以维护。
备忘录模式
备忘录模式
保存一个对象的某个状态
，以便在适当的时候恢复对象。
应用实例：1.
打游戏时的存档。 2.Windows 里的 ctri + z。3、数据库的事务管理。(回滚)
优点：
1、给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。 2、实现了信息的封装，使得用户不需要关心状态的保存细节。
缺点：
消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
观察者模式
对象之间一对多的依赖关系，当别观察者被修改时，被依赖的对象会受到通知,并做出相应的更新.
场景: Java Swing 里的各种监听器.
优点：
1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。
缺点：
1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
状态模式
类的行为是基于它的状态改变的。
优点：
1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确定状态种类。 3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
缺点：
1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。
空对象模式
一个空对象取代 NULL 对象实例的检查。Null 对象不是检查空值，而是反应一个不做任何动作的关系。这样的 Null 对象也可以在数据不可用的时候提供默认的行为。
策略模式
定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
优点：
1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
缺点：
1、策略类会增多。 2、所有策略类都需要对外暴露。
模板模式
一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。
优点：
1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3
、行为由父类控制，子类实现
。
缺点：
每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
访问者模式
我们使用了一个访问者类，它改变了元素类的执行算法。通过这种方式，元素的执行算法可以随着访问者改变而改变。( 主要将数据结构与数据操作分离。)
优点：
1、符合单一职责原则。 2、优秀的扩展性。 3、灵活性。
缺点：
1、具体元素对访问者公布细节，违反了迪米特原则。 2、具体元素变更比较困难。 3、违反了依赖倒置原则，依赖了具体类，没有依赖抽象。