设计模式-命令模式

命令模式是一种行为设计模式,用于将请求封装为对象,从而实现请求方与接收方的解耦。这种模式允许灵活地添加新命令,支持撤销/重做操作,并便于实现命令队列。在系统中,当操作具备命令语义且可能频繁变化时,使用命令模式可以提高代码的可维护性和扩展性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化,对请求排队或记录请求日志,以及支持可撤销的操作

命令模式( Command Pattern) 是对命令的封装,每一个命令都是一个操作:请求的一方 发出请求要求执行一个操作;接收的一方收到请求,并执行操作。命令模式解耦了请求方和接 收方,请求方只需请求执行命令,不用关心命令是怎样被接收,怎样被操作以及是否被执行⋯等。
命令模式属于行为型模式。

命令模式的应用层场景

当系统的某项操作具备命令语义时,且命令实现不稳定(变化),那么可以通过命令模式解 耦请求与实现,利用抽象命令接口使请求方代码架构稳定,封装接收方具体命令实现细节。接 收方与抽象命令接口呈现弱耦合(内部方法无需一致),具备良好的扩展性。命令模式适用于 以下应用场景:

  1. 现实语义中具备 “命令”的操作(如命令菜单,shell 命令⋯);
  2. 请求调用者和请求的接收者需要解耦,使得调用者和接收者不直接交互;
  3. 需要抽象出等待执行的行为,比如撤销(Undo)操作和恢复(Redo)等操作;
  4. 需要支持命令宏(即命令组合操作)。

命令模式的UML类图

public interface ICommand {
    void execute();
}
复制代码
public class ConcreteCommand implements ICommand{
    private final Receiver receiver;

    public ConcreteCommand(Receiver receiver) {
        this.receiver = receiver;
    }

    @Override
    public void execute() {
        receiver.action();
    }
}
复制代码
public class Receiver {
    public void action(){
        System.out.println("接收方接收到命令并执行");
    }
}
复制代码
public class Invoker {
    private final ICommand command;

    public Invoker(ICommand command) {
        this.command = command;
    }

    public void action(){
        command.execute();
    }
}
复制代码
public class Test {
    public static void main(String[] args) {
        ConcreteCommand concreteCommand = new ConcreteCommand(new Receiver());
        Invoker invoker = new Invoker(concreteCommand);
        invoker.action();
    }
}
复制代码

从上面的类图中就可以发现InvokerReceiver是没有耦合的,Invoker通过CommandReceiver建立联系的,这里 Invoker就相当于我们平时写业务中的一个业务逻辑的实现,你可以理解成是一个 service,而 Receiver相当于这个业务中的具体某个功能的实现,如果此时业务的需求需要变动,此时我们只需要更改CommandReceiver的应用或者为了符合开闭原则我们完全可以重新创建一个Command,对应者新的Receiver即可,这样对该对于我们整体的业务逻辑是没有改动的。

同时也可以结合装饰器模式,在原有的功能基础上增加一些其他的功能比如日志的收集等等,如果命令不是一个单独的命令而是一个命令的集合 Command会对应着多个命令,同时 Receiver也对应这多个方法,如果能对 Receiver进行抽象,这不就演变成了桥接模式,变成了command和Receiver两个变化的维度,这样扩展性更好

命令模式优缺点

优点:

  1. 通过引入中间件(抽象接口),解耦了命令请求与实现;
  2. 扩展性良好,可以很容易地增加新命令;
  3. 支持组合命令,支持命令队列;
  4. 可以在现有命令的基础上,增加额外功能(比如日志记录…,结合装饰器模式更酸爽)。

缺点:

  1. 具体命令类可能过多;
  2. 命令模式的结果其实就是接收方的执行结果,但是为了以命令的形式进行架构,解耦请求与实现,引入了额外类型结构(引入了请求方与抽象命令接口),增加了理解上的困难(不过这 也是设计模式带来的一个通病,抽象必然会引入额外类型;抽象肯定比紧密难理解)。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值