23种设计模式 - 行为变化（Command - Visitor）

其他设计模式 👉 23种设计模式(C++)🔗
每一种都有对应理解的相关代码示例 → Git原码 ⌨

行为变化

Command

动机（Motivation）

• 在软件构建过程中，“行为请求者”与“行为实现者“通常呈现一种”紧耦合“。但某些场合——比如需要对行为进行”记录、撤销/重做（undo/redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。
• 在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一个组行为抽象为对象，可以实现二者之间的松耦合。

模式定义

​ 将一个请求（行为）封装为一个对象，从而使你可用不用的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。 ——《设计模式》GoF

结构（Structure)

要点总结

• Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。
• 实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个“命令”封装为一个“复合命令”MacroCommand。
• Command模式与C++中的函数对象有些类似。但二者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，但有性能损失；C++函数对象以函数签名来定义行为接口规范，更灵活，性能更高。

Visitor

动机（Motivation）

• 在软件构建过程中，由于需求的变化，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。
• 如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？

模式定义

​表示一个作用于某对象结构中的各元素的操作。使得可以在不改变（稳定）各元素的类的前提下定义（扩展）作用于这些元素的新车操作（变化）。 ——《设计模式》GoF

结构（Structure)

要点总结

• Visitor模式通过所谓双重分发（double dispatch）来实现在不更改（不添加心的操作-编译时）Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作（支持变化）
• 所谓双重分发即Visitor模式中间包括了两个多态分发（注意其中的多态机制）：第一个为accept方法的多态辨析；第二个为visitElementX方法的多态辨析。
• Visitor模式的最大缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。因此Visitor模式适用于“Element类层次结构稳定，而其中的操作却经常面临频繁改动”。