首页 > 其他分享 >第16章 命令模式(Command Pattern)

第16章 命令模式(Command Pattern)

时间:2023-06-11 14:08:12浏览次数:40  
标签:16 Pattern void 模式 命令 Command doc public


命令模式(Command Pattern)

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

TerryLee,2006年7月

概述

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

意图

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

结构图

Command模式结构图如下:

第16章 命令模式(Command Pattern)_.net

图1  Command模式结构图

生活中的例子

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

第16章 命令模式(Command Pattern)_callback_02

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

Command模式解说

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

第16章 命令模式(Command Pattern)_command_03

图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模式解决这类问题的优雅之处,先对命令对象进行抽象:

第16章 命令模式(Command Pattern)_设计模式_04

图4

示意性代码:

/** <summary>  

/// 抽象命令  

/// </summary>  

public abstract class DocumentCommand  

{  
    Document _document;  

    public DocumentCommand(Document doc)  

      
{  
        this._document = doc;  
    }  

    /** <summary>  

    /// 执行  

    /// </summary>  

    public abstract void Execute();  

}

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

第16章 命令模式(Command Pattern)_设计模式_05


图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的依赖。如下:

第16章 命令模式(Command Pattern)_command_06

图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模式。

第16章 命令模式(Command Pattern)_设计模式_07

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

第16章 命令模式(Command Pattern)_.net_08

图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设计模式》


作者: TerryLee

标签:16,Pattern,void,模式,命令,Command,doc,public
From: https://blog.51cto.com/u_130277/6457540

相关文章

  • 第13章 代理模式(Proxy Pattern)
    代理模式(ProxyPattern)——.NET设计模式系列之十四Terrylee,2006年5月摘要:在软件系统中,有些对象有时候由于跨越网络或者其他的障碍,而不能够或者不想直接访问另一个对象,如果直接访问会给系统带来不必要的复杂性,这时候可以在客户程序和目标对象之间增加一层中间层,让代理对象来代替目标......
  • 第12章 享元模式(Flyweight Pattern)
    享元模式(FlyweightPattern)——.NET设计模式系列之十三Terrylee,2006年3月摘要:面向对象的思想很好地解决了抽象性的问题,一般也不会出现性能上的问题。但是在某些情况下,对象的数量可能会太多,从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象,同时又不影响客户程序使用面......
  • 第10章 组合模式(Composite Pattern)
    组合模式(CompositePattern)——.NET设计模式系列之十一Terrylee,2006年3月概述组合模式有时候又叫做部分-整体模式,它使我们树型结构的问题中,模糊了简单元素和复杂元素的概念,客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。意图将对象组合......
  • 第8章 桥接模式(Bridge Pattern)
    桥接模式(BridgePattern)——.NET设计模式系列之九Terrylee,2006年2月概述在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridg......
  • [cf1662J]Training Camp
    对于一个元素,注意到其不合法当且仅当满足以下条件之一:自身、同行比其小、同列比其大的元素均未选自身、同行比其大、同列比其小的元素均未选将同行同列值相邻的元素连边,每个条件中的元素即构成一条从\(1\)到\(n\)的链另外,若某行/某列元素均未选,也会产生一条从\(1\)到\(n\)......
  • 第7章 适配器模式(Adapter Pattern)
    适配器模式(AdapterPattern)——.NET设计模式系列之八Terrylee,2006年2月概述在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。那么如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能......
  • 第5章 原型模式(Protype Pattern)
    原型模式(PrototypePattern)——.NET设计模式系列之六Terrylee,2006年1月概述在软件系统中,有时候面临的产品类是动态变化的,而且这个产品类具有一定的等级结构。这时如果用工厂模式,则与产品类等级结构平行的工厂方法类也要随着这种变化而变化,显然不大合适。那么如何封装这种动态的变化......
  • 第11章 外观模式(Façade Pattern)
    外观模式(FaçadePattern)——.NET设计模式系列之十二Terrylee,2006年3月概述在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖......
  • 第9章 装饰模式(Decorator Pattern)
    装饰模式(DecoratorPattern)——.NET设计模式系列之十Terrylee,2006年3月概述在软件系统中,有时候我们会使用继承来扩展对象的功能,但是由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。如......
  • odoo16弹出对话框中显示SearchPanel
    在odoo中,有些数据模型的Search视图可能会定义关于SearchPanel的部分,但这部分定义不会在弹出对话框中显示。如员工的list视图显示如下: 但如果我们在一个挑选员工的弹出对话框中,显示是这样子的。 这样如果员工较多,我们还要进一步输入搜索条件来进行过虑,不太方便操作。那如果......