设计模式-行为型

一． 责任链模式

这种模式中，有发送者和接收者。通常，每个接收者都包含对另一个接收者的引用，形成一条链，如果一个接收者不能处理该请求，那么它会把相同的请求传给下一个接收者，依次类推。

这种模式将请求的发送者和接收者解耦，但是不能保证请求一定被接收。

使用场景是有1. 多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。2. 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 3. 可动态指定一组对象处理请求。

这里有个特别形象的例子：
假设现在有个需求来了，首先是实习生拿到这个需求。
如果实习生能够实现，直接实现。如果不行，他把这个需求交给初级工程师。
如果初级工程师能够实现，直接实现。如果不行，交给中级工程师。
如果中级工程师能够实现，直接实现。如果不行，交给高级工程师。
如果高级工程师能够实现，直接实现。如果不行，交给 CTO。
如果 CTO能够实现，直接实现。如果不行，直接跟产品说，需求不做。

这种模式和装饰者模式有一定相似的地方。

二． 命令模式

根据菜鸟教程的描述，“在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适”。

对于这个描述，我现在的理解不深。我理解的是，将一个请求用一个对象进行封装，相当于在请求的发起者和请求之间加多一层，以便将请求者与请求进行解耦。

三． 解析器模式

这个看不太明白，感觉没有应用的场景。

四． 迭代器模式

对这个理解的也不深，感觉用的也不多。

五． 中介者模式

用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。

具体的做法是将交联型(网状)的关系转化为星型关系，1、系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象。 2、想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。缺点可能是中介者会庞大，变得复杂难以维护。具体的应用有mvc中的c的作用。

六． 备忘录模式(应用比较少？)

主要解决：所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。

何时使用：很多时候我们总是需要记录一个对象的内部状态，这样做的目的就是为了允许用户取消不确定或者错误的操作，能够恢复到他原先的状态，使得他有"后悔药"可吃。

如何解决：通过一个备忘录类专门存储对象状态。

关键代码：客户不与备忘录类耦合，与备忘录管理类耦合。

应用实例： 1、后悔药。 2、打game时的存档。 3、Windows 里的 ctri + z。 4、IE 中的后退。 4、数据库的事务管理。

优点： 1、给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。 2、实现了信息的封装，使得用户不需要关心状态的保存细节。

缺点：消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。

七． 观察者模式
当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知它的依赖对象。观察者模式属于行为型模式。应用是mvc中的事件机制。

八． 状态模式
将一个状态封装为一个对象(状态对象)，这个对象会依赖于持有该状态的对象。状态对象有一个或多个方法改变持有状态的对象的行为。应用有: 状态机，行为树的动作节点等。

九． 空对象模式
to be continued……

十． 策略模式

意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

主要解决：在有多种算法相似的情况下，使用 if…else 所带来的复杂和难以维护。

何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。

如何解决：将这些算法封装成一个一个的类，任意地替换。

关键代码：实现同一个接口。

应用实例： 1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2、飞机game里面的bullet。

优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。

缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。

十一. 模板模式
to be continued……

十二. 访问者模式
to be continued……

to be continued