Java设计模式（26）行为型设计模式

Java设计模式（26）行为型设计模式：行为型设计模式涉及到算法和对象间职责的分配。该模式不仅描述对象或类的模式，还描述它们之间的通信模式。

changeClothes（Feman feman）;
changeClothes（Man man）;

（一）概述

这些模式刻划了在运行时难以跟踪的复杂的控制流。它们将你的注意力从控制流转义到对象间的联系方式上来。行为型设计模式包括11种：策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式和解释器模式。

（二）区别

这11种行为模式并没有太多相似的地方，无论是编码结构还是各自的使用需求。

1）策略模式

当一个函数规定了入参（即同样的参数），但通过不同的算法可以得出不同的结果，这些不同的算法就称为策略。策略是根据用户的需求而定，如入参为整形 xxx（1,1），那么策略可以是加减乘除其中的一种，或者其他更复杂的运算。那么不同的策略就可以得到不同的值，如加值为2，减值为0，乘值和除值均为1。

2）模板方法模式

定义一个父类模板作为规范：定义一个抽象对象，对象里包括某个业务的逻辑函数，该逻辑函数一般由多个简单函数组成，这些简单函数都是抽象化，由子类来具体化。简单来说就是父类骨架里同一业务由同样的逻辑顺序实现，但是由不同的子类具体化得出不同的结果。如吃饭，定义了基本业务逻辑：点单、吃和买单。可以有模板A：菜谱点单，吃面条，请客；模板B：IPAD点单，吃红烧肉，AA买单。当然，还有更多的方式实现点单、吃和买单。

（注）可以发现，模板方法模式与策略模式在实现业务目的上有相似的地方，都是提供多种方案提供选择，不同的是策略模式对所有方案都规定了同样的入参，即前提条件已确定；而模板方法模式任何条件均不确定，由子类自由扩展。

3）观察者模式

观察者模式，也叫"发布-订阅"模式，主要包括观察管理者和观察者，这两个角色有点类似于事件管理器和事件。将事件都添加进事件管理器中，当事件管理器满足一定条件时，就会触发相应的事件进行响应。比如用手机订阅人民日报，A、B两人都订阅了人民日报，当人民日报发布时，通过触发通知事件，A和B都收到了日报信息。但当某天B取消订阅后，B将从人民日报对象通知列表中移除。人民日报发布时，没有为B触发通知事件，此时只有A收到了日报信息。

4）迭代器模式

引用java.util.Iterator以实现快速遍历集合，也可以根据特殊需求对Iterator自定义。

5）责任链模式

有一系列对象，他们都实现相同的接口或继承相同的抽象对象，对象间呈链式引用，使每个对象都有能处理问题的机会。如A、B、C三个对象，A引用B，B引用C，此时有一个问题需要处理，但不知道ABC哪个能处理，只知道它们其中一个可以解决问题，此时A先去解决，A解决不了时，由其引用的B去解决，当B也解决不了时，由B引用的C去解决，直到问题解决为止。若中途B已经解决了问题，那么就直接返回结果，不会再调用到C。

6）命令模式

命令模式目的是实现“行为请求者”与“行为实现者”的解耦。如人用遥控器控制电视，在这种场景下，人就是“行为请求者”，而电视就是“行为实现者”，遥控器则是命令提交者，目的是对人与电视解耦。该模式要注意的是，这三种角色缺一不可，而且遥控器（命令提交者）必须通过引用电视（行为实现者）的方式来实现切换频道等操作。

7）备忘录模式

备忘录模式旨在保存某对象之前某个时刻的状态数据，这样以后就可将该对象恢复到原先保存的状态。此处要注意的是备忘录模式正常情况下都只保存数据对象，当需要恢复时只需将保存的数据对象重新设置到原始对象中即可。如软件中的撤销功能，软件会将撤销前当前软件的状态数据保存下来，当用户撤销时，只需将之前保存的状态值重新初始化对象即可。

8）状态模式

状态模式在代码结构上与创建型的工厂方法模式有点类似。定义一个状态管理者负责状态条件的判断，通过客户端传入的不同的状态条件使用不同的状态实现者。每一个状态实现者为一个实体类，通常通过静态方法的方式去实现不同状态操作。

9）访问者模式

该模式相对以上几种较为复杂也较为实用。指一个实体对象命名了多个名称相同，参数数量相同但参数格式不同的函数，调用时通过外部传入的参数即可自动识别执行相应函数的过程。如模特有一个函数为换衣服

 

changeClothes（Person person） //模特换衣服

但由于性别的差异，男模特与女模特有不同的换衣服方式，所以有人可能会这样修改：

manChangeClothes（Person person）//男模特换衣服
femanChangeClothes（Person person）//女模特换衣服

这只是两种情况，看起来还好，但如果还分老人模特换衣服、小孩模特换衣服，那么换衣服的不同的函数就越来越多，并不方便维护，所以最好每一个业务逻辑只有一种实现函数，即最开始的那种。但如果分类过多，那么意味着第一种实现函数里就有多个条件判断语句，并不满足开闭原则，不便于扩展。那么此时最好使用访问者模式，如：无论何种模特，都实现Person接口，此时原实体类修改如下：

changeClothes（Feman feman）;
changeClothes（Man man）;

两个函数名称是相同的，不同的是传入的参数格式，由于入参man和feman都实现相同的接口Person，所以客户端调用时只需

 

Person p = new Man();
changeClothes（p）;
Person p = new Feman();
changeClothes（p）;

函数changeClothes即会根据不同的入参格式选用不同的函数执行。

（注）这种模式在框架设计中常常用到，如在后台接口设计中，只要接口参数格式都实现同一接口，这时系统只需通过入参格式即可自行分配调用的实际接口，满足开闭原则，易于扩展。

10）中介者模式

中介者模式是指用一个中介者对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使耦合松散，而且可以独立地改变它们之间的交互。即有对象A与对象B，A与B之间的交互方式非常多，此时若A与B之间相互引用，则容易引起BUG或死循环。此时可以通过一个中介者对象来封装A与B之间的交互，实现A与B的解耦。该模式与命令模式的区别是：中介者模式A与B的交互是相互的，而命令模式则是单向交互，即遥控器作为中介者，只允许人来操作电视，而电视并不能操作人。

11）解释器模式

该模式较为简单，也并不常用，对实际软件功能实现也并没有太多影响，目的是为了程序员方便了解程序功能。

关于设计模式的系列文章就此也告一段落，毕竟是字字手码的文章，如果有不对或不尽详细的地方可以相互沟通学习。