【前言】
行为型模式有观察者模式、模板方法模式、命令模式、状态模式、职责链模式、解释器模式、中介者模式、访问者模式、策略模式、备忘录模式、迭代器模式。
在这里先介绍观察者模式、模板方法模式、命令模式、状态模式、职责链模式。
【内容】
观察者模式
定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
优点
（1）观察者和被观察者是抽象耦合的。
（2）建立一套触发机制。
缺点
（1）如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
（2）如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
（3）观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
何时使用
一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。
观察者模式—UML图
模板方法模式
定义一个操作的算法骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
优点
（1）封装不变部分，扩展可变部分。
（2）提取公共代码，便于维护。
（3）行为由父类控制，子类实现。
缺点
每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
何时使用
有一些通用的方法。
模板方法模式—UML图
命令模式
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；可以对请求排队或记录请求日志，以及支持可撤销的操作。
优点
（1）降低了系统耦合度。
（2）新的命令可以很容易添加到系统中去。
缺点
使用命令模式可能会导致某些系统有过多的具体命令类。
何时使用
在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
命令模式—UML图
状态模式
允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎修改了它的类。
优点
（1）封装了转换规则。
（2）枚举可能的状态，在枚举状态之前需要确定状态种类。
（3）将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
（4）允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
（5）可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
缺点
（1）状态模式的使用必然会增加系统类和对象的个数。
（2）状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
（3）状态模式对“开闭原则”的支持不是很大，对于可以切换状态的状态模式，增加新的状态类需要修改那些复杂状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需要修改对象类的源代码。
何时使用
代码中包含大量与对象状态有关的条件语句。
状态模式—UML图
职责链模式
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
优点
（1）降低耦合度。它将请求的发送者和接收者解耦。
（2）简化了对象。使得对象不需要知道链的结构。
（3）增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。
（4）增加新的请求处理类很方便。
缺点
（1）不能保证请求一定被接收。
（2）系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。
（3）可能不容易观察运行时的特征，有碍于除错。
何时使用
在处理消息的时候以过滤很多道。
职责链模式—UML图
