设计模式学习总结-命令模式（Cmmand Pattern)
问题：
在面向对象的软件设计中，经常会遇到一个（或一系列）对象，对象本身的数据存储与对象的操作耦合在一起。例如一个对象有add(),edit(),delete()方法，这样对象支持的方法很难扩展，如果需要加入update()就必须修改代码，客户端与对象也是紧耦合的。命令模式是将一类对象的功能（行为，功能）抽象成一个命令对象，客户端在使用的时候，只与该命令对象打交道，而不用与对象打交道，分离命令的请求者和命令的执行者，降低了耦合性，可以使用不同的请求对客户进行参数化提高了程序设计的灵活性。
定义：
命令模式（Command）模式，将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
意图：
提供一个抽象的Command接口，将执行命令操作的方法封装到Command类接口中，ConcreteCommand实现这个Command接口方法，通过调用Receiver实例变量处理请求。客户端定义一个Invoker对象存储该concreteCommand对象,该invoker通过调用command对象的递交一个请求。
参与者：
•抽象命令角色（Command）：
定义命令的接口，声明执行的方法。
具体命令角色（ConcreteCommand）：
命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
•请求者（Invoker）：
要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
•接收者（Receiver、执行者）：
接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
•客户端（Client）：
创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。
UML图：
实例说明：
诺基亚手机工厂
公司（Client）通知生产部（Invoker），生产两部n8,两部n9,生产部通过“命令模式”，将生产任务交给手机工厂（Receiver），生产手机。
uml图如下：
代码：
/// 手机生产命令接口（Command）
/// </summary>
public interface ICreatePhoneCommand
{
void Execute();
}
/// <summary>
/// N8手机生产具体命令类（ConcreteCommand）
/// </summary>
public class CreateNokiaN8Command : ICreatePhoneCommand
{
PhoneFactory phoneFactory = null;
public CreateNokiaN8Command(PhoneFactory _phoneFactory)
{
phoneFactory = _phoneFactory;
}
public void Execute()
{
phoneFactory.CreateNokiaN8();
}
}
/// <summary>
/// N8手机生产具体命令类（ConcreteCommand）
/// </summary>
public class CreateNokiaN9Command : ICreatePhoneCommand
{
PhoneFactory phoneFactory = null;
public CreateNokiaN9Command(PhoneFactory _phoneFactory)
{
phoneFactory = _phoneFactory;
}
public void Execute()
{
phoneFactory.CreateNokiaN9();
}
}
/// <summary>
/// 手机生产工厂（Receiver）具体的手机生产
/// </summary>
public class PhoneFactory
{
public void CreateNokiaN8()
{
System.Console.WriteLine("一部Nokia N8 生产完成");
}
public void CreateNokiaN9()
{
System.Console.WriteLine("一部Nokia N9 生产完成");
}
}
/// <summary>
/// 生产部对象（Invoker）接收生产信息，制定生产清单。通知PhoneFactory生产
/// </summary>
public class LiaisonCreate
{
List<ICreatePhoneCommand> createPhoneCommandList = new List<ICreatePhoneCommand>();
/// <summary>
/// 添加生产任务
/// </summary>
/// <param name="_createPhoneCommand"></param>
public void AddCreatePhoneTask(ICreatePhoneCommand _createPhoneCommand)
{
createPhoneCommandList.Add(_createPhoneCommand);
}
/// <summary>
/// 撤销生产任务
/// </summary>
/// <param name="_createPhoneCommand"></param>
public void CancelCreatePhoneTask(ICreatePhoneCommand _createPhoneCommand)
{
createPhoneCommandList.Remove(_createPhoneCommand);
}
/// <summary>
/// 执行生产
/// </summary>
public void CreatePhone()
{
foreach (var createPhoneCommand in createPhoneCommandList)
{
createPhoneCommand.Execute();
}
}
}
public void CommandTest()
{
//初始化生产部联系人
LiaisonCreate liaisonCreate = new LiaisonCreate();
//初始化生产工厂
PhoneFactory phoneFactory = new PhoneFactory();
//设置生产清单
liaisonCreate.AddCreatePhoneTask(new CreateNokiaN8Command(phoneFactory));
liaisonCreate.AddCreatePhoneTask(new CreateNokiaN8Command(phoneFactory));
liaisonCreate.AddCreatePhoneTask(new CreateNokiaN9Command(phoneFactory));
liaisonCreate.AddCreatePhoneTask(new CreateNokiaN9Command(phoneFactory));
//取消一部N9的生产
liaisonCreate.CancelCreatePhoneTask(new CreateNokiaN9Command(phoneFactory));
//开始执行生产
liaisonCreate.CreatePhone();
System.Console.Read();
}
优点：
•命令模式将发出命令的责任和执行命令的责任分割开，降低系统的耦合度。
•新的命令可以很容易地加入到系统中。只要实现了抽象命令接口的具体命令类就可以与接收者相关联。
•可以比较容易地设计一个组合命令，形成一个轻量级的事件队列
•命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。
•请求方不必知道接收请求的接口，执行命令的细节（只需客户端为concreteCommand对象指定一个receiver对象即可）起到了很好的封装隔离作用.
缺点：
•每一个命令都需要设计一个具体命令类，使用命令模式会导致某些系统有过多的具体命令类。
应用情景：
•系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
•系统需要在不同的时间指定请求、将请求排队和执行请求。
•系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
•系统需要将一组操作组合在一起，即支持宏命令。
