了解了这么多模式，在学习的过程中也设计到了很多行为模式，至于有哪些？可以一一道来。
迭代器模式
中介者模式
备忘录模式
观察者模式
状态模式
策略模式
模板方法模式
下文
访问者模式
职责连模式
命令模式
行为包括这么多，那么到底什么是行为模式呢？
行为模式是对在不同的对象之间划分责任和算法的抽象化。行为模式不仅仅是关于类和对象的，而且是关于它们之间的相互作用的。可分为类的行为模式和对象的行为模式。
类的行为模式：类的行为模式使用继承关系在几个类之间分配行为
对象的行为模式：使用对象的聚合来分配行为
看到这个模式第一感觉就是照葫芦画瓢的一个模式，应该算是最常用的一种模式吧！最近临近毕业，很喜欢那些在外打工的同胞回来看我，因为回来就可以请我吃大餐啊！对于吃饭，当然也有固定的模式，点单-吃东西-买单。就这么简单的一个流程呗！关键就在于点什么餐了 点单，买单的过程是重复的，所有重复的代码可以上升到父类，而不是让每个点餐都重复这个过程。这就是所谓的模仿方法模式。
定义：
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
结构图：
基本代码：
abstractclass是抽象类，其实也就是一抽象模板，定义并实现了一个模板方法。
concreteclass，实现父类所定义的一个或多个抽象方法。每一个abstractclass都可以有任意多个concreteclass与之对应，而每一个concreteclass都可以给出这些抽象方法的不同实现，从而使得顶级逻辑的实现各有不相同
客户端调用：
“工作这么长时间了，为什么就不给我涨工资呢？”满含抱怨的口气说道。
“我也想给你长工资啊！看着你每天的尽心尽力，可是我没有这个权利啊！”经理很耐心的讲述到。
“如果你是因为什么事情而请假一两天的话，我到可以有这个权利处理，可是毕竟财政大权不在咱们手里啊！心有余而力不足……”经理补充道。
其实我也知道经理人好，所以本以为这件事情就这样不了了之了，可是某天经理说总经理同意给你加工资了，你在公司的表现都众人皆知。这样当然就高兴了！
把自己处理不了的事情交给下一个人，总会有一个能够有权利来解决。这就是所谓的职责连模式。
使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
客户端代码，向链上的具体处理者对象提交请求
handler类，处理一个处理请示的接口
具体的处理者对象类
好处：
使用此模式，最主要的目的是想让请求不间断，而且我还可以随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。当然如果一个请求有可能到了链的末端都得不到处理，或者因为没有正确配置而得不到处理，这就很糟糕了，所以在使用的时候一定要考虑全面。
很喜欢没事的时候去超市的时候小逛一次，随便找个理由来犒劳一下自己，尽管没有什么需要犒劳的！不过这次算是一次小小的成就吧！最起码这次谈论到购物我明白了一个复杂的设计模式啊！
表示一个作用于某对象结构中的各个元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
访问者模式适用于数据结构相对稳定的系统，就如上述中，如果访问者过多又或者购买的东西过多的话，那么抽象方法则就变得不稳定了。 访问者模式把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化。
目的：
把处理从数据结构分离出来。前提当然是有比较稳定的数据结构哈！
使用此模式的优点：
就是增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中。
描述了这么多，就这三种模式而言，其实他们三个共同的特点顾名思义都属于行为型模式了，控制着类和对象的行为。至于不同，其实每个模式都有每个模式的优点：
模板方法模式：定义一个模板，这样的话，就是对算法的结构有着更多的控制权，不至于有重复的代码啊！
职责连模式：目的就是让过程不间断，每个对象都有着各自的分工，减少了对象之间的耦合。
访问者模式：最主要的一点则是符合单一职责原则，元素类中需要封装在访问者中的操作必定是与元素本身关系不大且是易变的操作，并且由于已经封装好，所以在不改变元素类本身的前提下，可以实现对变化部分的扩展，但是最大的不便也是最大的特点就是增加闲的元素比较困难，所以在不确定的状况下，一般以不用的。