.Net行为型设计模式之命令模式(Command)

2022-11-13 08:11:42 模式 命令 设计

一、动机(Motivate)

在我们的现实生活中有很多例子可以拿来说明这个模式,我们还拿吃饺子这个事情来说。我的奶奶说了,今天想吃饺子,发出了命令,然后我奶奶就去看电视去了。我们夫妻俩收到命令就开始和面,做饺子馅,包饺子。饺子包好了,我们就休息一会,等下午5点就开始烧水煮饺子了,晚饭的时间到了,我奶奶按时吃上了饺子。还有很多例子,就不一一列举了。

在软件构建过程中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重做(undo/redo)、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象,可以实现二者之间的松耦合。

二、意图(Intent)

将一个请求封装为一个对象,从而使你可用不同的请求对客户(客户程序,也是行为的请求者)进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。                                 ——《设计模式GoF

三、结构图(Structure)

四、模式的组成

从命令模式的结构图可以看出,它涉及到五个角色,它们分别是:
(1)、客户角色(Client):创建具体的命令对象,并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端,而是在组装命令对象和接收者,或许,把这个Client称为装配者会更好理解,因为真正使用命令的客户端是从Invoker来触发执行。
(2)、命令角色(Command):声明了一个给所有具体命令类实现的抽象接口。
(3)、具体命令角色(ConcreteCommand):命令接口实现对象,是“虚”的实现;通常会持有接收者,并调用接收者的功能来完成命令要执行的操作。
(4)、请求者角色(Invoker):要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方,也就是说相当于使用命令对象的入口。
(5)、接受者角色(Receiver):接收者,真正执行命令的对象。任何类都可能成为一个接收者,只要它能够实现命令要求实现的相应功能。

五、命令模式的代码实现

下面以生活中吃饺子为例来说说如何实现命令模式吧。今天早上,我奶奶就发布了命令,说她老人家想吃猪肉大葱馅的饺子。我奶奶腿脚不好,就让我爸爸捎个话给我们夫妻俩,晚上要吃猪肉大葱馅的饺子。我瞬间就明白了,这个伟大的任务就落到我们夫妻俩肩上了。说做就做,保证晚饭能吃上热气腾腾的饺子,具体实现代码如下:

static void Main(string[] args)
{
    //奶奶想吃猪肉大葱馅的饺子
    PatrickLiuAndWife liuAndLai = new PatrickLiuAndWife();//命令接受者
    Command command = new MakeDumplingsCommand(liuAndLai);//命令
    PaPaInvoker papa = new PaPaInvoker(command); //命令请求者

    //奶奶发布命令
    papa.ExecuteCommand();

    //奶奶说不想吃饺子了
    papa.Undo();
}

//这个类型就是请求者角色--也就是我爸爸的角色,告诉奶奶要吃饺子
public sealed class PaPaInvoker
{
    //我爸爸从奶奶那里接受到的命令
    private Command _command;

    //爸爸开始接受具体的命令
    public PaPaInvoker(Command command)
    {
        this._command = command;
    }

    //爸爸给我们下达命令
    public void ExecuteCommand()
    {
        _command.MakeDumplings();
    }

    public void Undo()
    {
        _command.UndoMakeDumplings();
    }
}

//该类型就是抽象命令角色--Commmand,定义了命令的抽象接口,任务是包饺子
public abstract class Command
{
    //真正任务的接受者
    protected PatrickLiuAndWife _worker;

    protected Command(PatrickLiuAndWife worker)
    {
        _worker = worker;
    }

    //该方法就是抽象命令对象Command的Execute方法
    public abstract void MakeDumplings();
    public abstract void UndoMakeDumplings();

}

//该类型是具体命令角色--ConcreteCommand,这个命令完成制作“猪肉大葱馅”的饺子
public sealed class MakeDumplingsCommand : Command
{
    public MakeDumplingsCommand(PatrickLiuAndWife worker) : base(worker) { }

    //执行命令--包饺子
    public override void MakeDumplings()
    {
        //执行命令---包饺子
        _worker.Execute("今天包的是农家猪肉和农家大葱馅的饺子");
    }
    public override void UndoMakeDumplings()
    {
        //执行命令---撤销包饺子
        _worker.Execute("撤销包饺子");
    }
}

//该类型是具体命令接受角色Receiver,具体包饺子的行为是我们夫妻俩来完成的
public sealed class PatrickLiuAndWife
{
    //这个方法相当于Receiver类型的Action方法
    public void Execute(string job)
    {
        Console.WriteLine(job);
    }
}

六、命令模式的实现要点:

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

1、命令模式的优点:

(1)、命令模式使得新的命令很容易被加入到系统里。

(2)、可以设计一个命令队列来实现对请求的Undo和Redo操作。
(3)、可以较容易地将命令写入日志。
(4)、可以把命令对象聚合在一起,合成为合成命令。合成命令式合成模式的应用。

2、命令模式的缺点:

使用命令模式可能会导致系统有过多的具体命令类。这会使得命令模式在这样的系统里变得不实际。

3、命令模式的使用场景:

(1)、系统需要支持命令的撤销(undo)。命令对象可以把状态存储起来,等到客户端需要撤销命令所产生的效果时,可以调用undo方法把命令所产生的效果撤销掉。命令对象还可以提供redo方法,以供客户端在需要时,再重新实现命令效果。
(2)、系统需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命周期。意思为:原来请求的发出者可能已经不存在了,而命令对象本身可能仍是活动的。这时命令的接受者可以在本地,也可以在网络的另一个地址。命令对象可以串行地传送到接受者上去。
(3)、如果一个系统要将系统中所有的数据消息更新到日志里,以便在系统崩溃时,可以根据日志里读回所有数据的更新命令,重新调用方法来一条一条地执行这些命令,从而恢复系统在崩溃前所做的数据更新。
(4)、系统需要使用命令模式作为“CallBack(回调)”在面向对象系统中的替代。Callback即是先将一个方法注册上,然后再以后调用该方法。

七、.NET 中命令模式的实现

由于.NET有了Delegate,它很少很少用到Command。它只要需要用到行为抽象,它都用Delegate去做。因为这是Framework,这是和业务领域相关度不大的基础建设层面,它是不太需要用到OO的层面。对于我们来说,我们建议更多地用Command去实现。

到此这篇关于.Net行为型设计模式之命令模式(Command)的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持。

相关文章