设计模式之命令（Command）模式详解

原文转载自：http://www.cnblogs.com/zhenyulu/articles/69858.html感谢作者。

一、 命令（Command）模式

命令（Command）模式属于对象的行为模式【GOF95】。命令模式又称为行动（Action）模式或交易（Transaction）模式。命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

命令模式是对命令的封装。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。

每一个命令都是一个操作：请求的一方发出请求要求执行一个操作；接收的一方收到请求，并执行操作。命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。

二、 命令模式的结构

命令模式的类图如下：

 

命令模式涉及到五个角色，它们分别是：

• 客户（Client）角色：创建了一个具体命令(ConcreteCommand)对象并确定其接收者。
• 命令（Command）角色：声明了一个给所有具体命令类的抽象接口。这是一个抽象角色。
• 具体命令（ConcreteCommand）角色：定义一个接受者和行为之间的弱耦合；实现Execute()方法，负责调用接收考的相应操作。Execute()方法通常叫做执方法。
• 请求者（Invoker）角色：负责调用命令对象执行请求，相关的方法叫做行动方法。
• 接收者（Receiver）角色：负责具体实施和执行一个请求。任何一个类都可以成为接收者，实施和执行请求的方法叫做行动方法。

 

三、 命令模式的示意性源代码

// Command pattern -- Structural example   
using System; 
 
// "Command" 
abstract class Command 
{ 
  // Fields 
  protected Receiver receiver; 
 
  // Constructors 
  public Command( Receiver receiver ) 
  { 
    this.receiver = receiver; 
  } 
 
  // Methods 
  abstract public void Execute(); 
} 
 
// "ConcreteCommand" 
class ConcreteCommand : Command 
{ 
  // Constructors 
  public ConcreteCommand( Receiver receiver ) : 
    base ( receiver ) {} 
 
  // Methods 
  public override void Execute() 
  { 
    receiver.Action(); 
  } 
} 
 
// "Receiver" 
class Receiver 
{ 
  // Methods 
  public void Action() 
  { 
    Console.WriteLine("Called Receiver.Action()"); 
  } 
} 
 
// "Invoker" 
class Invoker 
{ 
  // Fields 
  private Command command; 
 
  // Methods 
  public void SetCommand( Command command ) 
  { 
    this.command = command; 
  } 
 
  public void ExecuteCommand() 
  { 
    command.Execute(); 
  } 
} 
 
/// <summary> 
///  Client test 
/// </summary> 
public class Client 
{ 
  public static void Main( string[] args ) 
  { 
    // Create receiver, command, and invoker 
    Receiver r = new Receiver(); 
    Command c = new ConcreteCommand( r ); 
    Invoker i = new Invoker(); 
 
    // Set and execute command 
    i.SetCommand(c); 
    i.ExecuteCommand(); 
  } 
}

 

四、 玉帝传美猴王上天

命令模式不是新的发明，在美猴王大闹天宫之前就有了。那时玉帝命令太白金星召美猴王上天："金星径入(水帘洞)当中，面南立定道：'我是西方太白金星，奉玉帝招安圣旨，下界请你上大，拜受仙录。'"玉帝是系统的客户端，太白金星是命令的发出者，猴王是命令的接收者，圣旨就是命令。玉帝的这一道命令就是要求猴王到上界报到。玉帝只管发出命令，而不管命令是怎样传达到美猴王的。太白金星负责将圣旨传到，可是美猴王怎么执行圣旨、何时执行圣旨是美猴王自己的事。果不然，个久美猴王就大闹了天宫。

这个模拟系统的设计如下：

五、 命令模式的实现

首先命令应当"重"一些还是"轻"一些。在不同的情况下，可以做不同的选择。如果把命令设计得"轻"，那么它只是提供了一个请求者和接收者之间的耦合而己，命令代表请求者实现请求。

相反，如果把命令设计的"重"，那么它就应当实现所有的细节，包括请求所代表的操作，而不再需要接收者了。当一个系统没有接收者时，就可以采用这种做法。

更常见的是处于最"轻"和最"重"的两个极端之间时情况。命令类动态地决定调用哪一个接收者类。

其次是否支持undo和redo。如果一个命令类提供一个方法，比如叫unExecute()，以恢复其操作的效果，那么命令类就可以支持undo和redo。具体命令类需要存储状态信息，包括：

1. 接收者对象实际上实施请求所代表的操作； 
2. 对接收者对象所作的操作所需要的参数； 
3. 接收者类的最初的状态。接收者必须提供适当的方法，使命令类可以通过调用这个方法，以便接收者类恢复原有状态。

如果只需要提供一层的undo和redo，那么系统只需要存储最后被执行的那个命令对象。如果需要支持多层的undo和redo，那么系统就需要存储曾经被执行过的命令的清单，清单能允许的最大的长度便是系统所支持的undo和redo的层数。沿着清单逆着执行清单上的命令的反命令（unExecute()）便是undo；沿着清单顺着执行清单上的命令便是redo。

六、 命令模式的实际应用案例

下面的代码使用命令模式演示了一个简单的计算器，并允许执行undo与redo。注意："operator"在C#中是关键词，所以在前面添加一个"@"将其变为标识符。

// Command pattern -- Real World example   
using System; 
using System.Collections; 
 
// "Command" 
abstract class Command 
{ 
  // Methods 
  abstract public void Execute(); 
  abstract public void UnExecute(); 
} 
 
// "ConcreteCommand" 
class CalculatorCommand : Command 
{ 
  // Fields 
  char @operator; 
  int operand; 
  Calculator calculator; 
 
  // Constructor 
  public CalculatorCommand( Calculator calculator, 
    char @operator, int operand ) 
  { 
    this.calculator = calculator; 
    this.@operator = @operator; 
    this.operand = operand; 
  } 
 
  // Properties 
  public char Operator 
  { 
    set{ @operator = value; } 
  } 
 
  public int Operand 
  { 
    set{ operand = value; } 
  } 
 
  // Methods 
  override public void Execute() 
  { 
    calculator.Operation( @operator, operand ); 
  } 
  
  override public void UnExecute() 
  { 
    calculator.Operation( Undo( @operator ), operand ); 
  } 
 
  // Private helper function 
  private char Undo( char @operator ) 
  { 
    char undo = ' '; 
    switch( @operator ) 
    { 
      case '+': undo = '-'; break; 
      case '-': undo = '+'; break; 
      case '*': undo = '/'; break; 
      case '/': undo = '*'; break; 
    } 
    return undo; 
  } 
} 
 
// "Receiver" 
class Calculator 
{ 
  // Fields 
  private int total = 0; 
 
  // Methods 
  public void Operation( char @operator, int operand ) 
  { 
    switch( @operator ) 
    { 
      case '+': total += operand; break; 
      case '-': total -= operand; break; 
      case '*': total *= operand; break; 
      case '/': total /= operand; break; 
    } 
    Console.WriteLine( "Total = {0} (following {1} {2})", 
      total, @operator, operand ); 
  } 
} 
 
// "Invoker" 
class User 
{ 
  // Fields 
  private Calculator calculator = new Calculator(); 
  private ArrayList commands = new ArrayList(); 
  private int current = 0; 
 
  // Methods 
  public void Redo( int levels ) 
  { 
    Console.WriteLine( "---- Redo {0} levels ", levels ); 
    // Perform redo operations 
    for( int i = 0; i < levels; i++ ) 
      if( current < commands.Count - 1 ) 
        ((Command)commands[ current++ ]).Execute(); 
  } 
 
  public void Undo( int levels ) 
  { 
    Console.WriteLine( "---- Undo {0} levels ", levels ); 
    // Perform undo operations 
    for( int i = 0; i < levels; i++ ) 
      if( current > 0 ) 
        ((Command)commands[ --current ]).UnExecute(); 
  } 
 
  public void Compute( char @operator, int operand ) 
  { 
    // Create command operation and execute it 
    Command command = new CalculatorCommand( 
      calculator, @operator, operand ); 
    command.Execute(); 
 
    // Add command to undo list 
    commands.Add( command ); 
    current++; 
  } 
} 
 
/// <summary> 
/// CommandApp test 
/// </summary> 
public class Client 
{ 
  public static void Main( string[] args ) 
  { 
    // Create user and let her compute 
    User user = new User(); 
 
    user.Compute( '+', 100 ); 
    user.Compute( '-', 50 ); 
    user.Compute( '*', 10 ); 
    user.Compute( '/', 2 ); 
 
    // Undo and then redo some commands 
    user.Undo( 4 ); 
    user.Redo( 3 ); 
  } 
}

 

七、 在什么情况下应当使用命令模式

在下面的情况下应当考虑使用命令模式：

1、使用命令模式作为"CallBack"在面向对象系统中的替代。"CallBack"讲的便是先将一个函数登记上，然后在以后调用此函数。

2、需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之，原先的请求发出者可能已经不在了，而命令对象本身仍然是活动的。这时命令的接收者可以是在本地，也可以在网络的另外一个地址。命令对象可以在串形化之后传送到另外一台机器上去。

3、系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来，等到客户端需要撤销命令所产生的效果时，可以调用undo()方法，把命令所产生的效果撤销掉。命令对象还可以提供redo()方法，以供客户端在需要时，再重新实施命令效果。

4、如果一个系统要将系统中所有的数据更新到日志里，以便在系统崩溃时，可以根据日志里读回所有的数据更新命令，重新调用Execute()方法一条一条执行这些命令，从而恢复系统在崩溃前所做的数据更新。

5、一个系统需要支持交易(Transaction)。一个交易结构封装了一组数据更新命令。使用命令模式来实现交易结构可以使系统增加新的交易类型。

八、 使用命令模式的优点和缺点

命令允许请求的一方和接收请求的一方能够独立演化，从而且有以下的优点：

• 命令模式使新的命令很容易地被加入到系统里。
• 允许接收请求的一方决定是否要否决（Veto）请求。
• 能较容易地设计-个命令队列。
• 可以容易地实现对请求的Undo和Redo。
• 在需要的情况下，可以较容易地将命令记入日志。
• 命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。
• 命令类与其他任何别的类一样，可以修改和推广。
• 你可以把命令对象聚合在一起，合成为合成命令。比如宏命令便是合成命令的例子。合成命令是合成模式的应用。
• 由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。

命令模式的缺点如下：

• 使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个，几百个甚至几千个具体命令类，这会使命令模式在这样的系统里变得不实际。

---