设计模式之行为型模式（一）

设计模式被分成了三大类型：创建型、结构型和行为型。本文介绍一下行为型模式中的观察者模式、模板方法模式、命令模式、状态模式和职责链模式。

观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

优点：观察者模式解除了主题和具体观察者的耦合，让耦合的双方都依赖于抽象，而不是依赖具体。从而使得各自的变化都不会影响另一边的变化。

缺点：依赖关系并未完全解除，抽象通知者依旧依赖抽象的观察者。

应用：（1）当一个对象的改变需要给变其它对象时，而且它不知道具体有多少个对象有待改变时。（2） 一个抽象某型有两个方面，当其中一个方面依赖于另一个方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。

模板方法模式：定义一个操作的算法骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

优点：（1）模板方法模式通过把不变的行为搬移到超类，去除了子类中的重复代码。（2）子类实现算法的某些细节，有助于算法的扩展。（3）通过一个父类调用子类实现的操作，通过子类扩展增加新的行为，符合“开放-封闭原则”。

缺点:每个不同的实现都需要定义一个子类，这会导致类的个数的增加，设计更加抽象。

应用：（1）在某些类的算法中，用了相同的方法，造成代码的重复。（2）控制子类扩展，子类必须遵守算法规则。

命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；可以对请求排队或记录请求日志，以及支持可撤销的操作。

优点：（1）解除了请求者与实现者之间的耦合，降低了系统的耦合度。(2)对请求排队或记录请求日志，支持撤销操作。(3)可以容易地设计一个组合命令。(4)新命令可以容易地加入到系统中。

缺点:因为针对每一个命令都需要设计一个具体命令类，使用命令模式可能会导致系统有过多的具体命令类。

应用：（1）当需要对行为进行“记录、撤销/重做”等处理时。（2）系统需要将请求者和接收者解耦，使得调用者和接收者不直接交互。（3系统需要在不同时间指定请求、请求排队和执行请求。（4）系统需要将一组操作组合在一起，即支持宏命令。

状态模式：允许一个对象的内在其状态改变时改变它的行为，让对象看起来似乎修改了它的类。

优点：（1）状态模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。（2）所有状态相关的代码都存在于某个ConcereteState中，所以通过定义新的子类很容易地增加新的状态和转换。（3） 状态模式通过把各种状态转移逻辑分不到State的子类之间，来减少相互间的依赖。

缺点：导致较多的ConcreteState子类。

应用：（1）当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式来。（2）一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态。

职责链模式：使多个对象有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

优点：(1) 职责链模式使得一个对象无须知道是其他哪一个对象处理其请求，对象仅需知道该请求会被处理即可，接收者和发送者都没有对方的明确信息，且链中的对象不需要知道链的结构，由客户端负责链的创建，降低了系统的耦合度。(2) 请求处理对象仅需维持一个指向其后继者的引用，而不需要维持它对所有的候选处理者的引用，可简化对象的相互连接。(3) 在给对象分派职责时，职责链可以给我们更多的灵活性，可以通过在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的职责。(4) 在系统中增加一个新的具体请求处理者时无须修改原有系统的代码，只需要在客户端重新建链即可，从这一点来看是符合“开闭原则”的。

缺点：(1) 由于一个请求没有明确的接收者，那么就不能保证它一定会被处理，该请求可能一直到链的末端都得不到处理；一个请求也可能因职责链没有被正确配置而得不到处理。(2) 对于比较长的职责链，请求的处理可能涉及到多个处理对象，系统性能将受到一定影响，而且在进行代码调试时不太方便。(3) 如果建链不当，可能会造成循环调用，将导致系统陷入死循环。

应用：(1) 有多个对象可以处理同一个请求，具体哪个对象处理该请求待运行时刻再确定，客户端只需将请求提交到链上，而无须关心请求的处理对象是谁以及它是如何处理的。(2) 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。（3) 可动态指定一组对象处理请求，客户端可以动态创建职责链来处理请求，还可以改变链中处理者之间的先后次序。