一、引言
起初餐馆吃饭都是客人和厨师直接沟通，菜谱是一样的，可是客人多了的时候，有的客人可能有急事不吃了要退单，还有的客人点很多菜需要记录类别和次序等现象，这时服务员角色的出现解决了问题。那么面对某些无法抵御变化的“紧耦合”的场景如何做程序设计呢？命令模式设计便出现了，使得“行为请求者”与“行为实现者”解耦，以便适应变化，让对象之间调用关系更加灵活。下面请看今天要学习的命令模式：
二、命令模式
定义：将一个请求封装为一个对象，从而使可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
下面是结构图：
下面是代码demo：
//接收者类 class Receiver { //真正执行命令 public void Action() { Console.WriteLine("执行命令"); } } //命令抽象类 abstract class Command { //命令应该知道接收者是谁，所以有Receiver这个对象 protected Receiver receiver; public Command(Receiver receiver) { this.receiver = receiver; } //执行命令操作 public abstract void Execute(); } //具体命令类 class ConcreteCommand : Command { public ConcreteCommand(Receiver receiver) : base(receiver) { } public override void Execute() { //调用接收者来执行命令 receiver.Action(); } } //调度类 要求命令执行这个请求 class Invoker { //调度者应该知道被请求的命令，所以有Command这个成员变量 private Command command; //设置命令 public void SetCommand(Command command) { this.command = command; } //执行命令 public void ExecuteCommand() { command.Execute(); } } class Program { static void Main(string[] args) { Receiver receiver = new Receiver(); Command command = new ConcreteCommand(receiver); Invoker invoker = new Invoker(); invoker.SetCommand(command); invoker.ExecuteCommand(); Console.Read(); } }
优点：
1.降低系统耦合度，解除请求者和实现者的耦合
2.组合命令，将多个命令装配成一个组合命令，即较容易设计一个命令队列和宏命令
3.增加一个新的命令很容易，无需改变现有的类
4.对请求排队或记录请求日志，支持可撤销的操作
缺点：
1.针对每一个命令设计一个具体的命令类，可能导致系统有过多的具体命令类
使用场景：
1.系统需要请求者和实现者解耦，调用者和接收者不直接交互
2.需要在不同的时间支持请求，对请求排队。一个命令对象和原来的请求者有不同的生命期。换言之，原来的请求发出者可能已经不在了，而命令对象本身仍然是活动的。这时命令接收者可以在本地，也可以在网络的另一个地址。命令对象可以在串行之后传送到另一台机器上去。
3.系统需要支持命令的撤销（undo）。命令对象可以把状态存储起来，等客户端需要撤销命令所产生效果时，可以调用undo方法，把命令所产生的效果撤销掉
4.如果一个系统要将系统中所有数据消息更新到日志里，以便在系统崩溃时，可以根据日志里读回所有数据的更新命令，重新调用方法一条一条执行命令，从而恢复系统在崩溃前所作的数据更新
5.使用命令模式作为“Callback”在面向对象系统中的替代。"Callback"即先将一个函数注册上，然后在以后调用此函数
关于命令模式的学习就到此结束了，希望能够帮到你，若有不足，欢迎斧正，感谢您的阅读。