NET设计模式 第二部分 行为型模式(16):命令模式(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设计模式》

时间: 2024-10-06 03:55:13

NET设计模式 第二部分 行为型模式(16):命令模式(Command Pattern)的相关文章

IOS设计模式之四(备忘录模式,命令模式)

本文原文请见:http://www.raywenderlich.com/46988/ios-design-patterns. 由 @krq_tiger(http://weibo.com/xmuzyq)翻译,如果你发现有什么错误,请与我联系谢谢. 备忘录(Memento)模式 备忘录模式快照对象的内部状态并将其保存到外部.换句话说,它将状态保存到某处,过会你可以不破坏封装的情况下恢复对象的状态,也就是说原来对象中的私有数据仍然是私有的. 如何使用备忘录模式 在ViewController.m中增加

Java进阶篇设计模式之八 ----- 责任链模式和命令模式

前言 在上一篇中我们学习了结构型模式的享元模式和代理模式.本篇则来学习下行为型模式的两个模式, 责任链模式(Chain of Responsibility Pattern)和命令模式(Command Pattern). 责任链模式 简介 责任链模式顾名思义,就是为请求创建了一个接收者对象的链.这种模式给予请求的类型,对请求的发送者和接收者进行解耦.这种类型的设计模式属于行为型模式.在这种模式中,通常每个接收者都包含对另一个接收者的引用.如果一个对象不能处理该请求,那么它会把相同的请求传给下一个接

Java设计模式之八 ----- 责任链模式和命令模式

前言 在上一篇中我们学习了结构型模式的享元模式和代理模式.本篇则来学习下行为型模式的两个模式, 责任链模式(Chain of Responsibility Pattern)和命令模式(Command Pattern). 责任链模式 简介 责任链模式顾名思义,就是为请求创建了一个接收者对象的链.这种模式给予请求的类型,对请求的发送者和接收者进行解耦.这种类型的设计模式属于行为型模式.在这种模式中,通常每个接收者都包含对另一个接收者的引用.如果一个对象不能处理该请求,那么它会把相同的请求传给下一个接

行为型模式:命令模式

LieBrother原文: 行为型模式:命令模式 十一大行为型模式之三:命令模式. 简介 姓名 :命令模式 英文名 :Command Pattern 价值观 :军令如山 个人介绍 : Encapsulate a request as an object,thereby letting you parameterize clients with different requests,queue or log requests,and support undoable operations. 将一个

17行为型模式之命令模式

概念 Command模式也叫命令模式 ,是行为设计模式的一种.Command模式通过被称为Command的类封装了对目标对象的调用行为以及调用参数. 在面向对象的程序设计中,一个对象调用另一个对象,一般情况下的调用过程是:创建目标对象实例:设置调用参数:调用目标对象的方法. 但在有些情况下有必要使用一个专门的类对这种调用过程加以封装,我们把这种专门的类称作command类. 整个调用过程比较繁杂,或者存在多处这种调用.这时,使用Command类对该调用加以封装,便于功能的再利用.- 调用前后需要

C#设计模式(15)——命令(Command Pattern)

一.前言 之前一直在忙于工作上的事情,关于设计模式系列一直没更新,最近项目中发现,对于设计模式的了解是必不可少的,当然对于设计模式的应用那更是重要,可以说是否懂得应用设计模式在项目中是衡量一个程序员的技术水平,因为对于一个功能的实现,高级工程师和初级工程师一样都会实现,但是区别在于它们实现功能的可扩展和可维护性,也就是代码的是否“优美”.可读.但是,要更好地应用,首先就必须了解各种设计模式和其应用场景,所以我还是希望继续完成设计模式这个系列,希望通过这种总结的方式来加深自己设计模式的理解. 二.

策略模式Vs命令模式

阅读本篇文章前,你需要对策略模式和命令模式有一定的了解. 策略模式:主要用于封装算法,封装起来的好处就是可是随意替换算法. 命令模式:请求者给一个具体的命令,然后命令到底怎么执行的,执行的流程如何,他无需关心.例如,给我上一盘菜.它只是下了一个命令,然后服务员(接受请求)去叫厨房的师傅炒菜(执行者).整个执行过程,请求者不需要关心,它只需要给出一条命令,自然有人会帮忙处理他的这条指令. 下面我们结合类图分析一下策略模式: 策略模式Vs命令模式

进入编辑模式 vim命令模式 vim实践

进入编辑模式编辑模式,就是我们可以进行修改文档,配置的模式i 在当前字符前插入I(大写) 在光标所在行行首插入a 在当前字符后面插入A(大写) 在所在行行尾插入o 在当前行下面另起一行插入O(大写) 在当前行上面另起一行插入 ·····vim命令模式查找:/加你要查找的字符:·替换:(:1,21s/yang/huang/g)意思为在1-21行里将yang替换为huang(不加g只会替换一行中出现的第一个)·不加g的样子·(:1,$s/yang/huang/g)意思为1-最后一行里将yang替换为

vim进入编辑模式 , vim命令模式 ,vim实践

vim 的三种常用模式 一般模式 移动光标位置 删除,复制,粘贴 进入编辑模式 "i" 当前字符前插入 "I" 在光标所在行的行首插入 "a" 在当前字符后插入 "A" 在光标所在行尾插入 "o" 在当前行的下一行插入新的一行 "O" 在当前行的上一行插入新的一行 "Esc键" 退出编辑模式 进入命令模式 退出编辑模式后按":"或者"/&