五 设计模式 行为型模式 (五个设计模式)
本文目录导航：
设计模式（五）行为型模式
在上一篇结构型模式中，我们以功能为基本单位，研究了一些设计模式，用于实现功能转换、功能组合、功能封装等目的。
我们知道，面向对象编程有两个核心元素：对象、对象间通信协作。
从面向对象的角度看，任何系统和功能，都是由一个个对象，相互分工合作实现的。
推而广之，很多系统也都是这样组织和运行的。
本章的设计模式，列举了通用场景下常用功能机制的经典实现方法，讲解了经典实现中是如何高效组织对象、控制对象协作交互的，具有很好的参考价值。
示例：责任链模式，就是把程序处理对象前后排列起来，形成一条处理线。
处理线上需要被处理的信息，在处理线上向下传递，任何一个节点都可以随时中断传递。
GUI系统中的事件传递机制（在Javascript中叫做事件冒泡），是责任链模式最典型的应用之一。
当某一事件发生时，最顶层GUI对象会首先收到事件，但是它先不处理，而是依次交给命中的子GUI对象处理。
当子GUI对象返回为False时，表示事件未被接收，此时父GUI对象才真正对发生的事件进行业务处理。
可以看出，事件传递机制，是一种增强版的责任链模式，它的节点处理权，经历了向下和向上的双向传递过程。
总结：当项目中一个数据对象，需要被多个处理对象进行处理时，可以将处理对象链接起来，然后把数据对象传递给头节点，随着处理的进行，数据对象的处理权会在处理链中流动，从而完成整个处理过程。
责任链模式结构适用于需求固定的场景，用于实现简单高效的处理机制。
假如需求不断变化，而且功能很复杂，那么用责任链模式很可能就无法胜任了，需要采用新的高复杂度的设计。
例如，如果想要数据对象在所有处理对象中根据状态来实现跳转，可以选择使用状态机等其他方案来实现。
示例：想要实现撤销、重做、事务等功能，可以使用此设计模式。
通常在编辑器、数据库中有此类功能需求。
命令也就是请求，或者叫调用。
命令模式要求将请求参数和请求相关的方法封装在一起。
请求对象中封装了实现“撤销”、“重做”、“事务”功能所需要的所有信息，实现了关联信息的高内聚，所以可以实现我们想要的功能。
例如，可以在请求对象中保存修改之前的值、修改之后的值。
利用修改之前的值，可以实现“撤销”功能；利用修改之后的值，可以实现“重做”功能。
如果将所有请求对象都记录下来，并按照先后顺序排列起来，形成“撤销重做”堆栈，这样就可以实现连续的“撤销”、“重做”。
“事务”则是“撤销”与“重做”的结合体，正常执行流程等同于“重做”，发生错误需要回滚，等同于“撤销”。
如果不采用这种方式，会导致实现这些功能的信息，分散在源码中多个地方，或者已经丢失，没有保存，就无法实现“撤销”、“重做”、“事务”功能。
同时，实现请求参数高内聚，也可以很方便地将它们保存到磁盘上，保存到文件的过程叫做“序列化”，从文件中读取的过程叫“反序列化”。
这里的序列指的就是二进制流。
Qt中与命令模式相关的部分是：Undo Framework，里面有示例项目，不熟悉的同学可以抽点时间看一看。
示例：顾名思义，解释器模式是用来实现解释器的。
解释器是这样一个程序：解释器以符合语法的文本为输入，解释输入内容，完成一定的计算功能。
文本可以在程序运行时动态加载，动态解释、动态执行。
实现简单的解释器：命令行程序，如ping命令、cd命令等； 实现复杂的解释器：脚本语言解释器，如python，lua，javascript；计算器。
我们知道，在GUI图形用户界面被发明之前，人类和程序之间的交互是通过敲命令行实现的，缺点是使用难度较大，门槛较高。
在GUI发明以后，交互更加友好，电脑更加易于使用了，所以也更加普及了。
但是GUI交互的缺点在于，不够灵活，对参数的控制粒度不够细致。
例如，现在大多数开发者都使用集成开发环境来开发软件，一般情况下都使用默认参数，比较方便。
但是如果你想要更改某些编译选项，可能还是需要直接修改底层的编译命令。
命令相对于GUI元素更加灵活，过于灵活的地方用GUI比较难于实现，例如组合、递归、跳转等等。
在这些场景下，使用解释器是非常合适的。
但是通常情况下，这个模式并不常用。
示例：在需要多次遍历同一个数据集合的时候，为了少些一些for，或者想要把遍历过程封装起来，降低耦合，就可以使用迭代器模式。
这个模式非常常用。
迭代器就是一个专门用来遍历数组的类。
它只需要实现两个接口：hasNext()、next()。
hasNext()接口用于控制循环何时停止；next()接口用于取出当前位置的数据元素，并将遍历指针指向下一个元素。
当然，构造迭代器对象的时候，需要将数据集合传递给迭代器，让迭代器知道要遍历哪些数据。
原本需要用for循环来遍历的代码，现在通过封装，提取出了“遍历”这一功能所需要的必要信息，定义了两个接口，把不必要暴露的信息封装在了迭代器中，妥妥的实现了解耦。
示例：中介者模式是指，在原本直接通信的对象之间，添加一个通信中间层，使对象间通信变为间接通信，降低对象间的耦合。
此模式和代理模式基本思想上是一致的。
二者的区别是：代理模式是通过加一个中间层，来实现两个原本很难交互的功能主体，实现顺畅交互；中介者模式是为了降低对象间通信时的耦合而提出的，为的是提高代码的可维护性。
比较大的项目中会用到，一般存在于某些框架中。
因为大的项目中对象繁多，通信也比较复杂，适合使用中介者模式。
在大的项目中，一般会有一个全局的通信管理器，任何对象都可以使用通信管理器提供的接口，将自己注册为某一个具有唯一ID消息的发送者和接收者。
这样发送者只需要发送消息，不需要管谁来接收，不需要拥有发送者的实例指针，发出消息后，已注册的接收者都会收到消息。
接收者不需要管信号是谁发的，即不需要拥有发送者的实例指针。
所以，中介者模式也可以叫“通信中介模式”。
示例：这个模式和状态存档功能是绑定在一起的。
为了在程序中实现状态存档功能，可以使用备忘录模式。
原例子中有三个类，个人觉得没有必要，这里我们简化成两个类，即备忘录模式中有两个类：状态对象类和状态对象管理类。
状态对象类是状态字段是集合，并提供了存取接口；状态对象管理类负责组织和保存状态对象。
当然实际实现中可以根据需求增加类，配合使用，完成状态保存恢复。
当一个对象会影响到其他多个对象时，即当对象间存在一对多关系时，使用观察者模式。
一般应用于单向通知的场景，如GUI中鼠标事件、按键事件、窗口事件通知。
使用Qt中的信号槽机制可以实现此模式。
“一”是指发生变化的那个对象，“多”是指需要获取此变化通知的对象组。
其中，变化消息是单向地由“一”到“多”传递的。
如果不是单向的或者对象间不是一对多的关系，更加复杂，就需要重新思考其他对象间通信模型。
如果不使用此模式，可能会导致观察者不能动态增加或删除；可能会造成发送者的业务代码和接收者的响应代码混在一起，耦合严重。
使用此模式，需要为观察者设计一个基类，并设计一个接收通知的接口，所有观察者需要实现通知接口；所有观察者指针可以保存在队列中，实现动态增删。
状态模式用于实现状态机。
如果一个程序功能中存在某些状态，在一定情况下，这些状态可以互相转换，并且在转换前后需要作出对应的操作，这种情况下使用状态机来实现就非常合适。
如果不使用状态机（状态模式），一般的实现方法是使用一连串的if-else，或者使用长长的switch-case来实现。
这样做的缺点，一方面状态判断不够高效，另一方面是业务代码集中在一块，不好维护。
使用状态机，每个状态都是一个类，相关的业务代码分布到各自的状态类中，能够实现不同的状态及与状态相关的业务代码解耦。
同时某个状态和下一个状态是关联好的，在状态切换时，效率更高，不需要执行长长的判断。
Qt中已实现状态机框架，The State Machine Framework，在此框架下，我们可以更加专注于业务实现，而不是状态机本身的技术细节。
示例：使用基类保存子类对象通常有两种做法： 第一种方法用指针是基本方法，但是指针用起来要非常小心，要考虑内存释放的问题。
此时空对象就可以用空指针表示。
第二种方法用基类对象保存子类对象，这种方法使用起来相对省心，不用与指针打交道，使用者不用直接管理内存。
例如Qt中的Qt XML C++ Classes类的设计就是采用这种方式设计的。
这种情况下，因为不使用指针，就需要使用空对象来代替空指针。
可以仿造Qt XML中的类进行设计。
一般需要提供isNull()接口，对象类型转换接口等。
策略模式和桥接模式类似，用于实现功能切换与组合。
二者区别在于，策略模式专注于一个功能的不同实现方式；桥接模式专注于多个功能之间的组合。
将功能抽象成单独的类，功能切换只需要切换不同的功能子类即可，同一个功能需要实现同一个功能接口。
示例：模板模式应该是我们最熟悉的。
这里的模板就是接口类，接口类定义了使用者和功能提供者之间交互的函数列表。
子类负责功能的具体实现。
示例：访问者模式用于将数据结构与数据操作相分离。
访问者模式和迭代器模式类似。
迭代器模式一般用来遍历数组，所以没有把for封装起来。
而访问者模式可以遍历一切类型的数据结构，具体的遍历过程被封装在接收者内部。
同时，对每一个遍历得到的数组元素的操作，被封装在访问者内部。
每一种对元素不同的操作，都需要新建一个访问者类。
接收者需要实现accept()接口，访问者需要实现visit()接口。
每种设计模式都有使用场景，都有优点和缺点。
随着需求的改变，任何一种设计模式可能都将不再适用。
设计模式(5)｜状态机模式（State Machine Pattern）
状态机模式，作为行为型设计模式之一，旨在描述对象随其内部状态改变而呈现的不同行为。
在这一模式中，对象的行为取决于其当前状态，且状态间的转换规则定义明确。
此模式的核心在于解耦对象行为与其状态，便于管理和维护复杂系统。
尤其在系统具备多样状态和复杂状态转换逻辑时，状态机模式能简化设计与实现。
应用状态机模式时，需遵循以下步骤以确保设计逻辑清晰，满足预期需求：遵循这些步骤能帮助开发者在设计与实现过程中保持清晰思路，确保最终系统的功能与性能达到预期。
状态机模式在多个领域广泛适用，涵盖但不限于：状态机模式广泛应用于描述系统随时间与外部条件变化而演变的行为模式。
通过分解系统为一组状态与状态转换规则，状态机模式能清晰展示系统行为，助力复杂系统的控制与管理。
面试中，状态机相关问题可能涉及：通过理解这些问题及答案，能更好地掌握状态机模式，并展示其在实际项目中的应用与优势。
[因为我不懂啊]-什么是状态机编程（设计模式）（3）
上一篇文章写完之后，我一直在想做一个游戏示例，想将之前学到的状态机模式运用在其中。
然而一直遇到各种奇怪的bug（之后写出来），所以一直没有完成这件事。
而且加之自己又犯懒了，所以我决定做一件更简单的事，以更容易接近的目标来引诱懒的不行的自己。
废话说完，来说正经事了。
前几天认真看了一篇 博客-游戏状态机（侵立删），觉得挺不错的，建议盆友们认真看一看。
读完博客之后，之前计划的示例貌似有了头绪，（废话型）总结出来，实现一个游戏状态机结构需要进行如下几步：
我要做一个简单的UI切换示例，所以简述需求就是: 打开程序进入主界面，主界面中点击开始游戏，进入游戏界面，游戏界面中点击结束游戏，进入结算界面，结算界面可以点击回到主界面，进入主界面，也可以点击重新开始游戏，再次进入游戏界面。
从需求描述来看，状态有三个:
事件有四个:
然后（装模作样的）画了一个状态转换表：
之前一篇文章中有提到过的，在Cocos2d-x游戏开发中，刚好使用Scene来作为控制器，由Scene来控制各层的出现和消失。
这里贴出Scene的源码(完整的源文件，包括了后续步骤才会出现的状态基类，以及派生的状态类)：
上面可以看到，Scene中主要包含了:
包含了以上内容，本示例中的这个Scene就能起到控制器的作用了。
状态基类是很有必要的，为了达到各个同级状态都能通过同一个控制器来进行状态转换的目标，各个状态类进行切换时必须有一套统一的流程。 这里贴出本示例中状态基类的源码:
这个源文件中包含了:
所有的派生状态类都会 include 这个文件，实现虚基类 GameTwoState 中的方法，所以所有的状态类都有统一的切换流程:
而且在完成某个事件，需要进行状态转换时，可以通过发送自定义事件来完成消息的传递，自定义事件名放在这里也是为了方便起见。
这里直接贴出几个State的源码了，其中包含注释，废话就不重复再写了:
到这里，上面所提到的步骤全部进行完了。
这个UI切换的状态机示例也就完成了。
在中，直接进入Scene中:
进入主界面 :
此时的Log:
点击Start，进入游戏界面 :
此时的Log:
<Exit>->MainLayer <Enter>->GameLayer <Execute> ->GameLayer
点击Over，进入结算界面 :
此时的Log:
<Enter>->GameLayer <Execute> ->GameLayer [Event]->Game_Over <Exit>->GameLayer
<Enter>->ResultLayer <Execute> ->ResultLayer
点击Replay，重新进入游戏界面 : 此时的Log:
<Enter>->GameLayer <Execute> ->GameLayer [Event]->Game_Over <Exit>->GameLayer
<Enter>->ResultLayer <Execute> ->ResultLayer [Event]->Result_Replay <Exit>->ResultLayer
<Enter>->GameLayer <Execute> ->GameLayer
点击Over，再次进入结算界面，然后在结算界面点击Home，回到主界面 上面的两次操作完成后，Log如下:
<Enter>->GameLayer <Execute> ->GameLayer [Event]->Game_Over <Exit>->GameLayer
<Enter>->ResultLayer <Execute> ->ResultLayer [Event]->Result_Replay <Exit>->ResultLayer
<Enter>->GameLayer <Execute> ->GameLayer [Event]->Game_Over <Exit>->GameLayer
<Enter>->ResultLayer <Execute> ->ResultLayer [Event]->Result_Home <Exit>->ResultLayer
<Enter>->MainLayer <Execute> ->MainLayer
这里用FSM实现UI切换示例只是众多方法中的一种，暂时还没有去比较它们的优劣。(使用markdown编辑器的经验值+1)
可能性多种多样，如果有小伙伴比较过这些方法。
求留言告知，求分享经验。
phper