命令模式(Command Pattern)

命令模式属于对象的行为模式。命令模式又称为行动(Action)模式或交易(Transaction)模式。
     命令模式是把一个请求或操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化，对请求排队或记录请求日志，可以提供命令的撤消和恢复功能。
一、引言
     命令模式是对命令的封装，命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。
     每一个命令都是一个操作：请求的一方发出请求要求执行一个操作；接收的一方收到请求，并执行操作。命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求一方的接口，更不必知道请求是怎么接收的，以及操作是否被执行、何时被执行，以及是怎么被执行的。
     命令模式允许请求的一方和接收请求的一方能够独立演化，从而具有以下的优点。
1）   命令模式使新的命令很容易的被加入到系统里
2）   允许接收请求的一方是否要否决(Veto)请求。
3）   能较容易的设计一个命令队列。
4）   可以容易的实现对请求的Undo和Redo。
5）   在需要的情况下，可以较容易的将命令记入日志。
对熟悉C语言的读者，命令模式就是面向对象的回呼(Callback)。Java语言虽然不支持函数指针，但是命令模式可以达到同样的目的
二、命令模式的结构
1、命令模式涉及到5个角色
1）客户角色：创建一个具体命令对象并确定其接收者。
2）命令角色：声明了一个给所有具体命令类的抽象接口。这是个抽象角色，由接口或抽象类实现。
3）具体命令角色：定义一个接收者和行为之间的弱耦合；实现execute()方法，负责调用接收者的相应操作。execute()方法通常叫做执行方法。
4）请求者角色：负责调用命令对象执行请求，相关的方法叫做行动方法。
5）接收者角色：负责具体实施和执行一个请求。任何一个类都可以成为接收者，实施和执行请求的方法叫行动方法
2、源代码清单
1）客户角色
public class Client
{
    public static void main(String[] args)
    {
        Receiver receiver = new Receiver();//定义一个接收者对象
        //创建一个具体命令对象，把接收者对象作为参数
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker( command );//定义一个请求者对象，将具体命令对象作为参数
        invoker.action();//请求者对象执行行动方法。
    }
}
2）请求者角色
public class Invoker
{
    private Command command;//定义一个命令对象
public Invoker(Command command)//构造方法，需要一个命令角色
    {
        this.command = command;
    }
    public void action()//命令角色执行execute()方法
    {
         command.execute();
}
}
3）接收者角色
public class Receiver
{
    public Receiver()
    {
        //write code here
    }
    public void action()
    {
        System.out.println("Action has been taken.");//接收者要执行的代码
    }
}
4）抽象命令角色
public interface Command
{
    void execute();//定义一个方法，让具体命令角色去实现
}
5）具体命令角色
public class ConcreteCommand implements Command
{
private Receiver receiver;    //定义一个接收者角色
public ConcreteCommand(Receiver receiver) //构造函数，把接收者作为参数
    {
        this.receiver = receiver;
    }
    public void execute()   //接收者执行行动方法
    {
        receiver.action();
    }
}
3、命令模式的活动序列
1）客户端创建一个具体命令对象(ConcreteCommmand)，并指明了接收者
2）请求者对象保存了具体命令对象(ConcreteCommmand)。
3）请求者对象通过调用action()方法发出请求。如果命令是能撤消(undo)，那么ConcreteCommmand保存了调用execute()方法之前的状态
4）ConcreteCommmand对象调用接收一方的方法执行请求。
4、Java语言内的例子：AWT的事件处理
    Java语言使用了命令模式处理java.awt库的事件委派处理模型。在这个事件处理模型里，命令对象实现AWT的listener接口，相当于命令接口。为把一个命令对象与一个AWT构件连接起来，需要把它登记成一个事件的lintener。构件只认识listener接口。而不在乎接口是怎么实现的，也不在意命令所代表的实际操作。
    如果一个视窗系统的命令都是由按钮构件代表，那么为了彰显命令模式，每个按钮都给出一个实现ActionListener接口的类，那么这些按钮类便是具体命令类，而ActionListener接口便是抽象命令角色。
    但是，AWT并不提供命令模式的撤消和恢复机制。为了支持撤消和恢复，就要在每个按钮类里存储局部的状态信息，记住命令的效果。由于AWT系统不提供这样的机制，因此需要程序自己实现这一机制。
1）示例：创世纪系统
     这个系统共有6个类/接口。
A、抽象命令角色
public interface CommandFromGod
{
   public void Execute();
}
B、请求者角色
public class TheWorld extends Frame implements ActionListener
{
   LetThereBeLightCommand btnLight;
   LetThereBeLandCommand btnLand;
   ResetCommand btnReset;
   GodRestsCommand btnExit;
   Panel p;
 
   public TheWorld()
   {
      super("This is the world, and God says...");
      p = new Panel();
      p.setBackground(Color.black);
 
      add(p);
      btnLight = new LetThereBeLightCommand("Let there be light", p);
      btnLand = new LetThereBeLandCommand("Let there be land", p);
      btnReset = new ResetCommand("Reset", p);
      btnExit = new GodRestsCommand("God rests");
 
      p.add(btnLight);
      p.add(btnLand);
      p.add(btnReset);
      p.add(btnExit);
 
      btnLight.addActionListener(this);
      btnLand.addActionListener(this);
      btnReset.addActionListener(this);
      btnExit.addActionListener(this);
      setBounds(100,100,400,200);
      setVisible(true);
   }
   //-----------------------------------------
   public void actionPerformed(ActionEvent e)
   {
      CommandFromGod obj = (CommandFromGod)e.getSource();
      obj.Execute();
   }
   //-----------------------------------------
   static public void main(String[] argv)
   {
      new TheWorld();
   }
}
C、具体命令角色—4个
public class LetThereBeLandCommand extends Button implements CommandFromGod
{
     Panel p;
     public LetThereBeLandCommand(String caption, Panel pnl)
     {
         super(caption);
         p = pnl;
     }
     public void Execute()
     {
         p.setBackground(Color.orange);
     }
}
public class LetThereBeLightCommand extends Button implements CommandFromGod
{
     Panel p;
     public LetThereBeLightCommand(String caption, Panel pnl)
     {
         super(caption);
         p = pnl;
     }
     public void Execute()
     {
         p.setBackground(Color.white);
     }
}
public class ResetCommand extends Button implements CommandFromGod
{
     Panel p;
     public ResetCommand(String caption, Panel pnl)
     {
         super(caption);
         p = pnl;
     }
     public void Execute()
     {
         p.setBackground(Color.black);
     }
}
public class GodRestsCommand extends Button implements CommandFromGod
{
 
     public GodRestsCommand(String caption)
     {
         super(caption);
     }
     public void Execute()
     {
         System.exit(0);
     }
}
三、命令模式的实现
     命令模式的实现有几个要考虑的问题
1、 首先，命令应当“重”一些还是“轻”一些，在不同的情况下，可以有不同的选择。如果把命令设计的“轻”一些，那么它只是提供了一个请求者和接收者之间的耦合而已，命令代表请求者实现请求。
     相反。如果把命令设计的“重”一些，那么它就应当实现所有的细节，包括请求所代表的操作，而不再需要接收者了。当一个系统没有接收者时，就可以采用这种做法。
     更常见的是处于最“轻”和最“重”的2个极端之间的情况。命令类动态的决定调用哪一个接收者类。
2、其次是否支持undo和redo。如果一个命令类提供一个方法，以恢复其操作的效果，那么这个命令类就可以支持undo和redo。具体命令类需要存储的状态信息包括
(1)接收者对象实际上实施请求所代表的操作
(2)对接收者对象所做的操作所需的参数
(3)接收者类的最初的状态。接收者必须提供适当的方法，使命令可以通过调用这个方法，以便接收者类恢复状态
     如果只需要提供一层的undo和redo，那么系统只需要存储最后被执行的那个命令对象。如果需要执行支持多层的undo和redo，那么系统就需要存储曾经被执行过的命令的清单，清单能允许的最大长度便是系统所支持的undo和redo的层数。沿着清单逆着执行清单上的命令的反命令(unexecuted())便是undo；
沿着清单顺着执行清单上的命令便是redo。
四、在什么情况下应当使用命令模式
1、使用命令模式作为“回呼”在面向对象系统中的替代。“回呼”是先将一个函数登记，然后在以后调用此函数
2、需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。原先的请求发出者可能已经不在了，而命令对象本身仍然是活动的。这时命令的接收者可以是在本地，也可以在网络的另外一个地址。命令对象可以在串形化后传到另外一台机器上去。
3、系统需要支持命令的撤消。命令对象可以把状态存储起来，等到客户端需要撤消命令所产生的效果时，可以调用undo()方法，把命令产生的效果撤掉。命令对象还可以提供redo()方法，以供客户端在需要时，再重新实施命令的效果。
五、命令模式的优点和缺点
1、优点
(1)命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开
(2)命令类与其它任何类别的类一样，可以修改和推广
(3)可以把命令对象聚合在一起，合成为合成命令。
(4)由于加入新的具体命令类不影响其它的类，因此增加新的具体命令类很容易。
2、缺点
使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个，几百个甚至几千个具体命令类。这会使命令模式在这样的系统里变的不实际

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/matchcolor/archive/2006/09/28/1302173.aspx