设计模式学习笔记--Command命令模式

   命令模式是对命令的封装。通过封装把发出命令的责任和执行命令的责任分割开,委派给不同的对象。 命令(Command)模式属于对象的行为模式【GOF95】,它又称为行动(Action)模式或交易(Transaction)模式。
   每一个命令都是一个操作:请求的一方发出请求要求执行一个操作;接收的一方收到请求,并执行操作。命令模式允许请求的一方和接收的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的。
命令模式涉及到五个角色,它们分别是:

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

    代码实现:
   根据命令(Command)角色所要负责的工作,我们可分为两种方式来实现:

   1、一种是Seperate方式,此方式下命令(Command)角色仅确定一个接收者和执行该请求的动作,因此,它需要在子类中完成具体的命令操作,并通过请求者(Invoker)角色这一中间层来与接收者互动。
   
2、另一种是Combine方式,此时命令(Command)角色要自己实现所有命令功能,根本不需要请求者(Invoker)角色,它自己充当了中间层来与接收者互动。

   下面我们来用代码说明如何理解Command命令模式,程序如下图:
            
  一、传统的做法:不采用Command模式的情况

  1、定义一个类Car

Code

  2、使用这个类及其相关操作,写在Programme.cs中

Code

  这种情况下,把命令的接收者Car与行为(Start,Stop等操作)紧密耦合

  二、Seperate方式
  仍使用上面定义的类Car(它就是接收者Receiver角色),不同的是我们要加入以下角色
  1、命令Command角色CarSeperateCommand

Code

  
  2、具体命令(ConcreteCommand)角色:CarSeperateCommandClasses中内含的(StartCommand类,MoveForwardsCommand类,MoveBackwardsCommand类,StopCommand类)

Code

 
  3、请求者(Invoker)角色:CarSeperateInvoker,它充当客户与操作的中间层

Code

  4、客户(Client)角色:写在Programme.cs中

Code

  运行效果如下: 
                        

  三、Combine方式
   仍使用上面定义的类Car(它就是接收者Receiver角色),不同的是我们要加入以下角色
   1、命令Command角色CarCombineCommand:此处与Seperate方式最大的不同在于它要定义所有相关命令的接口,而不再是只定义一个Excute命令实现。

Code

   2、具体命令(ConcreteCommand)角色:此处与Seperate方式最大的不同在于它是在一个类中打包实现所以命令,它充当客户与操作的中间层。

Code

   
   3、客户(Client)角色:写在Program.cs中

Code

   运行效果如下:

                        

总结:

在什么情况下应当使用命令模式
1、使用命令模式作为"CallBack"在面向对象系统中的替代。"CallBack"讲的便是先将一个函数登记上,然后在以后调用此函数。
2、需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之,原先的请求发出者可能已经不在了,而命令对象本身仍然是活动的。这时命令的接收者可以是在本地,也可以在网络的另外一个地址。命令对象可以在串形化之后传送到另外一台机器上去。
3、系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来,等到客户端需要撤销命令所产生的效果时,可以调用undo()方法,把命令所产生的效果撤销掉。命令对象还可以提供redo()方法,以供客户端在需要时,再重新实施命令效果。
4、如果一个系统要将系统中所有的数据更新到日志里,以便在系统崩溃时,可以根据日志里读回所有的数据更新命令,重新调用Execute()方法一条一条执行这些命令,从而恢复系统在崩溃前所做的数据更新。
5、一个系统需要支持交易(Transaction)。一个交易结构封装了一组数据更新命令。使用命令模式来实现交易结构可以使系统增加新的交易类型。

使用命令模式的优点和缺点
命令允许请求的一方和接收请求的一方能够独立演化,从而且有以下的优点:

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

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

Command模式的几个要点:

1、  Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦,在面向对象语言中,常见的实现手段是“将行为抽象为对象”。
2、  实现Command接口的具体命令对象ConcreteCommand 有时候根据需要可能会保存一些额外的状态信息。
3、  通过使用Composite模式,可以将多个“命名”封装为一个“复合命令”MacroCommand。
4、  Command模式与C#中的Delegate有些类似。但两者定义行为接口的规范有所区别:Command以面向对象中的“接口-实现”类定义行为接口规范,更严格,更符合抽象原则:Delegate以函数签名来定义行为接口规范,更灵活,但抽象能力比较弱

前往:设计模式学习笔记清单
posted @ 2009-10-07 10:18  wsdj  阅读(859)  评论(1编辑  收藏  举报