本文通过遥控器与灯设备的示例介绍了命令模式，展示了如何通过命令模式将请求调用者（遥控器）与请求接收者（灯）解耦。在不使用命令模式的情况下，遥控器需要直接依赖于灯的具体操作，导致耦合性增加。命令模式通过定义Command接口和具体命令类，使得遥控器只需依赖于接口，实现了更高程度的灵活性。此外，文中还讨论了如何在命令模式中添加撤销功能，通过在Command接口中添加undo()方法，并在具体命令类中实现，遥控器可以记录并执行撤销操作。这样不仅增强了系统的可扩展性，还支持了历史操作的回溯。
首先，总而言之，命令模式的功能是：把 请求调用者 和 请求接收者 解耦。
一个命令模式示例：
示例类图：
类图中包含一个遥控器类、一个Command接口、一个LightOnCommand具体命令类和一个Light灯设备类。
Light的每一个操作对应实现一个Command具体类，Command具体类遵循Command接口。遥控器类的实现也仅针对Command接口编写。这样就做到了遥控器类和具体命令类均只依赖于Command接口，而不依赖彼此的实现，从而遥控器和命令解耦。
结果就是任何具体的Command类，只要遵循Command接口，都可以直接插入遥控器中使用。
真正执行命令的操作是写在具体的Command类里的（如execute()方法），而这个方法的调用时写在遥控器类里的。
注：女招待相当于遥控器。
如果上面这个示例不使用命令模式，会成什么样？
没想明白。
命令模式：将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
加入撤销：
加入撤销功能分两步：1. 遥控器类加入一个变量储存上一个命令的引用，记录下上一个命令是哪个命令在执行。2. 每个命令加入自己的undo()方法以及撤销操作所需的用于记录设备上一个状态的一些新变量，实现撤销操作。具体见下：
首先Command接口稍作修改：
接着，具体Command类分别实现自己的undo()方法：
最后，遥控器类记录下前一个执行的命令，并稍作修改：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
