引言
命令模式，我感觉“命令”就是任务，执行了命令就完成了一个任务。或者说，命令是任务，我们再从这个名字上并不知道命令的发出者和接受者分别是谁，为什么呢？因为我们并不关心他们是谁，发出命令的人发出命令，可以继续做其他的事情，接受命令的人执行任务就可以，不需要你发出命令，还要监督我们完成，只要我们完成任务是合格的就行。这种行为也就是“解耦”，命令模式用得比较少，一般都是在实际项目开发的后发现需要用的时候我们通过重构来实现。在现实生活中，我们也用这个设计模式，例如：我们去吃大排档，到店告诉服务员来盘啤酒小龙虾、烤鱼一份，一箱啤酒，过了一会告诉服务员不要烤鱼了，这里我们不需要关心具体是哪个大厨炒菜，只需要告诉服务员我们需要什么就可以了
命令模式介绍
命令模式的定义
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作
命令模式的结构图
命令模式的组成
从命令模式的结构图可以看出，它涉及到五个角色，它们分别是：
（1）、客户角色（Client）：创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。
（2）、命令角色（Command）：声明了一个给所有具体命令类实现的抽象接口。
（3）、具体命令角色（ConcreteCommand）：命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
（4）、请求者角色（Invoker）：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
（5）、接受者角色（Receiver）：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
命令模式的代码实现
第一版无模式
View Codeclass Program { static void Main(string[] args) { Barbecuer boy = new Barbecuer(); boy.BakeMutton(); boy.BakeMutton(); boy.BakeMutton(); boy.BakeChickenWing(); boy.BakeMutton(); boy.BakeMutton(); boy.BakeChickenWing(); Console.Read(); } } //烤肉串者 public class Barbecuer { //烤羊肉 public void BakeMutton() { Console.WriteLine("烤羊肉串!"); } //烤鸡翅 public void BakeChickenWing() { Console.WriteLine("烤鸡翅!"); } }这种方法可以看出命令的发送者将对命令接收者是强耦合的关系
第二版引入命令模式
//客户端 class Program { static void Main(string[] args) { //开店前的准备 Barbecuer boy = new Barbecuer(); Command bakeMuttonCommand1 = new BakeMuttonCommand(boy); Command bakeMuttonCommand2 = new BakeMuttonCommand(boy); Command bakeChickenWingCommand1 = new BakeChickenWingCommand(boy); Waiter girl = new Waiter(); //开门营业 顾客点菜 girl.SetOrder(bakeMuttonCommand1); girl.SetOrder(bakeMuttonCommand2); girl.SetOrder(bakeChickenWingCommand1); //点菜完闭，通知厨房 girl.Notify(); Console.Read(); } //服务员 public class Waiter { private IList<Command> orders = new List<Command>(); //设置订单 public void SetOrder(Command command) { if (command.ToString() == "命令模式.BakeChickenWingCommand") { Console.WriteLine("服务员：鸡翅没有了，请点别的烧烤。"); } else { orders.Add(command); Console.WriteLine("增加订单：" + command.ToString() + " 时间：" + DateTime.Now.ToString()); } } //取消订单 public void CancelOrder(Command command) { orders.Remove(command); Console.WriteLine("取消订单：" + command.ToString() + " 时间：" + DateTime.Now.ToString()); } //通知全部执行 public void Notify() { foreach (Command cmd in orders) { cmd.ExcuteCommand(); } } } //抽象命令 public abstract class Command { protected Barbecuer receiver; public Command(Barbecuer receiver) { this.receiver = receiver; } //执行命令 abstract public void ExcuteCommand(); } //烤羊肉串命令 class BakeMuttonCommand : Command { public BakeMuttonCommand(Barbecuer receiver) : base(receiver) { } public override void ExcuteCommand() { receiver.BakeMutton(); } } //烤鸡翅命令 class BakeChickenWingCommand : Command { public BakeChickenWingCommand(Barbecuer receiver) : base(receiver) { } public override void ExcuteCommand() { receiver.BakeChickenWing(); } } //烤肉串者 public class Barbecuer { public void BakeMutton() { Console.WriteLine("烤羊肉串!"); } public void BakeChickenWing() { Console.WriteLine("烤鸡翅!"); } }
命令模式的实现场景
在下面的情况下可以考虑使用命令模式：
- 系统需要支持命令的撤销（undo）。命令对象可以把状态存储起来，等到客户端需要撤销命令所产生的效果时，可以调用undo方法吧命令所产生的效果撤销掉。命令对象还可以提供redo方法，以供客户端在需要时，再重新实现命令效果。
- 系统需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命周期。意思为：原来请求的发出者可能已经不存在了，而命令对象本身可能仍是活动的。这时命令的接受者可以在本地，也可以在网络的另一个地址。命令对象可以串行地传送到接受者上去。
- 如果一个系统要将系统中所有的数据消息更新到日志里，以便在系统崩溃时，可以根据日志里读回所有数据的更新命令，重新调用方法来一条一条地执行这些命令，从而恢复系统在崩溃前所做的数据更新。
- 系统需要使用命令模式作为“CallBack(回调)”在面向对象系统中的替代。Callback即是先将一个方法注册上，然后再以后调用该方法。
命令模式优缺点
命令模式使得命令发出的一个和接收的一方实现低耦合，从而有以下的优点：
- 命令模式使得新的命令很容易被加入到系统里。
- 可以设计一个命令队列来实现对请求的Undo和Redo操作。
- 可以较容易地将命令写入日志。
- 可以把命令对象聚合在一起，合成为合成命令。合成命令式合成模式的应用。
命令模式的缺点：
- 使用命令模式可能会导致系统有过多的具体命令类。这会使得命令模式在这样的系统里变得不实际。
总结
命令模式能叫容易地设计一个命令队列，第二，在需要的情况下，可以较容易地将命令记入日志，第三，允许接受请求的一方是否否决请求。第四，可以容易地实现对请求的撤销与重做，第五，由于加进新的具体命令类不影响其它的类，因此新增新的具体命令类很容易，第六，命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开
永远不要让自己原地踏步--