设计模式-命令模式

news2024/11/20 20:31:55

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

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

命令模式的应用层场景

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

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

命令模式的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();
    }
}
复制代码

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

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