命令模式(Command Pattern)

设计模式 - 吕震宇

.NET设计模式系列文章

薛敬明的专栏

乐在其中设计模式(C#)

设计模式（18）－Command Pattern

一、 命令（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。
• 在需要的情况下，可以较容易地将命令记入日志。
• 命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。
• 命令类与其他任何别的类一样，可以修改和推广。
• 你可以把命令对象聚合在一起，合成为合成命令。比如宏命令便是合成命令的例子。合成命令是合成模式的应用。
• 由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。

命令模式的缺点如下：

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

---

参考文献：
阎宏，《Java与模式》，电子工业出版社
[美]James W. Cooper，《C#设计模式》，电子工业出版社
[美]Alan Shalloway  James R. Trott，《Design Patterns Explained》，中国电力出版社
[美]Robert C. Martin，《敏捷软件开发－原则、模式与实践》，清华大学出版社
[美]Don Box, Chris Sells，《.NET本质论 第1卷：公共语言运行库》，中国电力出版社
http://www.dofactory.com/Patterns/Patterns.aspx 

.NET设计模式（17）：命令模式（Command Pattern）

命令模式（Command Pattern）

——.NET设计模式系列之十七

TerryLee，2006年7月

概述

在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合[李建忠]。这就是本文要说的Command模式。

意图

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。[GOF 《设计模式》]

结构图

Command模式结构图如下：

图1  Command模式结构图

生活中的例子

Command模式将一个请求封装为一个对象，从而使你可以使用不同的请求对客户进行参数化。用餐时的账单是Command模式的一个例子。服务员接受顾客的点单，把它记在账单上封装。这个点单被排队等待烹饪。注意这里的"账单"是不依赖于菜单的，它可以被不同的顾客使用，因此它可以添入不同的点单项目。

图2  使用用餐例子的Command模式对象图

Command模式解说

在众多的设计模式中，Command模式是很简单也很优雅的一种设计模式。Command模式它封装的是命令，把命令发出者的责任和命令执行者的责任分开。我们知道，一个类是一组操作和相应的一些变量的集合，现在有这样一个类Document，如下：

图3

示意性代码：

/// <summary>

/// 文档类

/// </summary>

public   class  Document

{
    /// <summary>

    /// 显示操作

    /// </summary>

    public void Display()

    {
        Console.WriteLine("Display");
    } 

    /// <summary>

    /// 撤销操作

    /// </summary>

    public void Undo()

    {
        Console.WriteLine("Undo");
    }

    /// <summary>

    /// 恢复操作

    /// </summary>

    public void Redo()

    {
        Console.WriteLine("Redo");
    }
}

一般情况下我们使用这个类的时候，都会这样去写：

class  Program

{
    static void Main(string[] args)

    {
        Document doc = new Document();

        doc.Display();

        doc.Undo();

        doc.Redo();
    }
}

这样的使用本来是没有任何问题的，但是我们看到在这个特定的应用中，出现了Undo/Redo的操作，这时如果行为的请求者和行为的实现者之间还是呈现这样一种紧耦合，就不太合适了。可以看到，客户程序是依赖于具体Document的命令（方法）的，引入Command模式，需要对Document中的三个命令进行抽象，这是Command模式最有意思的地方，因为在我们看来Display()，Undo()，Redo()这三个方法都应该是Document所具有的，如果单独抽象出来成一个命令对象，那就是把函数层面的功能提到了类的层面，有点功能分解的味道，我觉得这正是Command模式解决这类问题的优雅之处，先对命令对象进行抽象：

图4

示意性代码：

/// <summary>

/// 抽象命令

/// </summary>

public   abstract   class  DocumentCommand

{
    Document _document;

    public DocumentCommand(Document doc)

    {
        this._document = doc;
    }

    /// <summary>

    /// 执行

    /// </summary>

    public abstract void Execute();

}

其他的具体命令类都继承于该抽象类，如下：

图5

示意性代码：

/// <summary>

/// 显示命令

/// </summary>

public   class  DisplayCommand : DocumentCommand

{
    public DisplayCommand(Document doc)

        : base(doc)
    {    

    }

    public override void Execute()

    {
        _document.Display();   
    }
}


/// <summary>

/// 撤销命令

/// </summary>

public   class  UndoCommand : DocumentCommand

{ 
    public UndoCommand(Document doc)

        : base(doc)
    {   

    }

    public override void Execute()

    {
        _document.Undo();   
    }
}


/// <summary>

/// 重做命令

/// </summary>

public   class  RedoCommand : DocumentCommand

{
    public RedoCommand(Document doc)

        : base(doc)
    { 

    }

    public override void Execute()

    {
        _document.Redo();   
    } 
}

现在还需要一个Invoker角色的类，这其实相当于一个中间角色，前面我曾经说过，使用这样的一个中间层也是我们经常使用的手法，即把A对B的依赖转换为A对C的依赖。如下：

图6

示意性代码：

/// <summary>

/// Invoker角色

/// </summary>

public   class  DocumentInvoker

{
    DocumentCommand _discmd;

    DocumentCommand _undcmd;

    DocumentCommand _redcmd;

    public DocumentInvoker(DocumentCommand discmd,DocumentCommand undcmd,DocumentCommand redcmd)
    {

        this._discmd = discmd;

        this._undcmd = undcmd;

        this._redcmd = redcmd;

    }

    public void Display()

    {
        _discmd.Execute();
    }

    public void Undo()

    {
        _undcmd.Execute();
    }

    public void Redo()

    {
        _redcmd.Execute();
    }
}

现在再来看客户程序的调用代码：

class  Program

{
    static void Main(string[] args)

    {

        Document doc = new Document();


        DocumentCommand discmd = new DisplayCommand(doc);

        DocumentCommand undcmd = new UndoCommand(doc);

        DocumentCommand redcmd = new RedoCommand(doc);


        DocumentInvoker invoker = new DocumentInvoker(discmd,undcmd,redcmd);

        invoker.Display();

        invoker.Undo();

        invoker.Redo();

    }
}

可以看到：

1．在客户程序中，不再依赖于Document的Display()，Undo()，Redo()命令，通过Command对这些命令进行了封装，使用它的一个关键就是抽象的Command类，它定义了一个操作的接口。同时我们也可以看到，本来这三个命令仅仅是三个方法而已，但是通过Command模式却把它们提到了类的层面，这其实是违背了面向对象的原则，但它却优雅的解决了分离命令的请求者和命令的执行者的问题，在使用Command模式的时候，一定要判断好使用它的时机。

2．上面的Undo/Redo只是简单示意性的实现，如果要实现这样的效果，需要对命令对象设置一个状态，由命令对象可以把状态存储起来。

.NET中的Command模式

在ASP.NET的MVC模式中，有一种叫Front Controller的模式，它分为Handler和Command树两个部分，Handler处理所有公共的逻辑，接收HTTP Post或Get请求以及相关的参数并根据输入的参数选择正确的命令对象，然后将控制权传递到Command对象，由其完成后面的操作，这里面其实就是用到了Command模式。

图7  Front Controller 的处理程序部分结构图

图8 Front Controller的命令部分结构图

Handler 类负责处理各个 Web 请求，并将确定正确的 Command 对象这一职责委派给 CommandFactory 类。当 CommandFactory 返回 Command 对象后，Handler 将调用 Command 上的 Execute 方法来执行请求。具体的实现如下

Handler类：

/// <summary>

/// Handler类

/// </summary>

public   class  Handler : IHttpHandler

{
    public void ProcessRequest(HttpContext context)

    {

        Command command = CommandFactory.Make(context.Request.Params);

        command.Execute(context);

    }

    public bool IsReusable

    {
        get

        {
            return true;
        }
    }
}

Command接口：

/// <summary>

/// Command

/// </summary>

public   interface  Command

{
    void Execute(HttpContext context);
}

CommandFactory类：

/// <summary>

/// CommandFactory

/// </summary>

public   class  CommandFactory

{
    public static Command Make(NameValueCollection parms)

    {

        string requestParm = parms["requestParm"];

        Command command = null;

        //根据输入参数得到不同的Command对象

        switch (requestParm)

        {
            case "1":

                command = new FirstPortal();

                break;

            case "2":

                command = new SecondPortal();

                break;

            default:

                command = new FirstPortal();

                break;
        }

        return command;

    }
}

RedirectCommand类：

public   abstract   class  RedirectCommand : Command

{
    //获得Web.Config中定义的key和url键值对，UrlMap类详见下载包中的代码

    private UrlMap map = UrlMap.SoleInstance;

    protected abstract void OnExecute(HttpContext context);

    public void Execute(HttpContext context)

    {
        OnExecute(context);

        //根据key和url键值对提交到具体处理的页面

        string url = String.Format("{0}?{1}", map.Map[context.Request.Url.AbsolutePath], context.Request.Url.Query);

        context.Server.Transfer(url);

    }
}

FirstPortal类：

public   class  FirstPortal : RedirectCommand

{
    protected override void OnExecute(HttpContext context)

    {
        //在输入参数中加入项portalId以便页面处理

        context.Items["portalId"] = "1";

    }
}

SecondPortal类：

public   class  SecondPortal : RedirectCommand

{
    protected override void OnExecute(HttpContext context)

    {
        context.Items["portalId"] = "2";
    }
}

效果及实现要点

1．Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。

2．实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。

3．通过使用Compmosite模式，可以将多个命令封装为一个“复合命令”MacroCommand。

4．Command模式与C#中的Delegate有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，更符合抽象原则；Delegate以函数签名来定义行为接口规范，更灵活，但抽象能力比较弱。

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

适用性

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

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

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

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

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

总结

Command模式是非常简单而又优雅的一种设计模式，它的根本目的在于将“行为请求者”与“行为实现者”解耦。

更多的设计模式文章可以访问《.NET设计模式系列文章》

 

参考资料

Erich Gamma等，《设计模式：可复用面向对象软件的基础》，机械工业出版社

Robert C.Martin，《敏捷软件开发：原则、模式与实践》，清华大学出版社

阎宏，《Java与模式》，电子工业出版社

Alan Shalloway James R. Trott，《Design Patterns Explained》，中国电力出版社

MSDN WebCast 《C#面向对象设计模式纵横谈(14)：Command命令模式(结构型模式)》

袁剑，《领悟Web设计模式》