设计模式之【命令模式】，方法调用的花式玩法-CSDN博客

本文链接：https://blog.csdn.net/A_art_xiang/article/details/130706288

文章目录

一、什么是命令模式
二、使用示例
三、源码中的命令模式
- 1、Thread

一、什么是命令模式

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

原文：将一个请求封装成医德对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

在软件系统中，行为请求者与行为实现者通常是一种紧耦合关系，因为这样的实现简单明了。但紧耦合关系缺乏扩展性，在某些场合中，当需要为行为进行记录，撤销或重做等处理时，只能修改源码。而命令模式通过为请求与实现间引入了一个抽象命令接口，解耦了请求与实现，并且中间件是抽象的，它可以有不同的子类实现，因此其具备扩展性。所以，命令模式的本质是解耦命令请求与处理。

1、命令模式使用场景

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

系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
现实语义中具备“命令”的操作（如命令菜单、shell命令等）。
系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
系统需要在不同的时间指定请求、将请求排队和执行请求。
需要支持命令宏（即命令组合操作）。

2、命令模式的主要角色

在这里插入图片描述
命令模式包含以下主要角色：

抽象命令类（Command）角色：定义命令的接口，声明执行的方法。
具体命令（Concrete Command）角色：具体的命令，实现命令接口；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
实现者/接收者（Receiver）角色：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
调用者/请求者（Invoker）角色：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

从命令模式的UML类图中可以看出：Command的出现就是作为Receiver和Invoker的中间件，解耦了彼此。而之所以引入Command中间件，主要有以下两方面的原因：
（1）解耦请求与实现：即解耦了Invoker和Receiver，因为在UML类图中，Invoker是一个具体的实现，等待接收客户端传入命令（即Invoker与客户端耦合），Invoker处于业务逻辑区域，应当是一个稳定的结构。而Receiver是属于业务功能模块，是经常变动的；如果没有Command，则Invoker紧耦合Receiver，一个稳定的结构依赖了一个不稳定的结构，就会导致整个结构都不稳定了。这也就是Command引入的原因：不仅仅是解耦请求与实现，同时稳定（Invoker）依赖文档（Command），结构还是稳定的。
（2）扩展性增强：扩展性体现在两个方面：① Receiver属于底层细节，可以通过更换不同的Receiver达到不同的细节实现；② Command接口本身就是抽象的，本身就具备扩展性，而且由于命令对象本身就具备抽象，如果结合装饰器模式，功能扩展简直如鱼得水。

注！在一个系统中，不同的命令对应不同的请求，也就是说无法把请求抽象化，因此命令模式中的Receiver是具体实现；但是如果在某一个模块中，可以对Receiver进行抽象，其实这就变相使用到了桥接模式（Command类具备两个变化的维度：Command和Receiver），这样子的扩展性会更加优秀。

3、命令模式优缺点

优点：

降低系统的耦合度。命令模式能将调用操作的对象与实现该操作的对象解耦。
增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类，它满足“开闭原则”，对扩展比较灵活。
可以实现宏命令。命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。
方便实现 Undo 和 Redo 操作。命令模式可以与备忘录模式结合，实现命令的撤销与恢复。
可以在现有命令的基础上，增加额外功能（比如日志记录等等，结合装饰器模式效果更佳）。

缺点：

使用命令模式可能会导致某些系统有过多的具体命令类。
命令模式的结果其实就是接收方的执行结果，但是为了以命令的形式进行架构，解耦请求与实现，引入了额外类型结构（引入了请求方与抽象命令接口），增加了理解上的困难（不过这也是设计模式带来的一个通病，抽象必然会引入额外类型；抽象肯定比紧密难理解）。
使用频率低、理解难度大，只在非常特定的应用场景下才会用到。

4、命令模式注意事项及细节

将发起请求的对象与执行请求的对象解耦。发起请求的对象是调用者，调用者只要调用命令对象execute()方法就可以让接收者工作，而不必知道具体的接收者对象是谁、是如何实现的，命令对象会负责让接收者执行请求的动作，也就是说：“请求发起者”和“请求执行者”之间的解耦是通过命令对象实现的，命令对象起到了纽带桥梁的作用。
容易设计一个命令队列，只要把命令对象放到队列，就可以多线程的执行命令。
容易实现对请求的撤销和重做。
空命令也是一种设计模式，它为我们省去了判空的操作。可以使用接口适配器模式，将Command接口适配为一个空类。

二、使用示例

1、命令模式的一般写法

//抽象命令接口
public interface ICommand {
   
    void execute();
}

//具体命令
public class ConcreteCommand implements ICommand {
   
    // 直接创建接收者，不暴露给客户端
    private Receiver mReceiver;

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

    public void execute() {
   
        this.mReceiver.action();
    }
}

//请求者
public class Invoker {
   
    private ICommand mCmd;

    public Invoker(ICommand cmd) {
   
        this.mCmd = cmd;
    }

    public void action() {
   
        this.mCmd.execute();
    }
}

//接收者
public class Receiver {
   
    public void action() {
   
        System.out.println("执行具体操作");
    }
}

public class Test {
   
    public static void main(String[] args) {
   
        ICommand cmd = new ConcreteCommand(new Receiver());
        Invoker invoker = new Invoker(cmd);
        invoker.action();
    }
}

2、播放器功能案例

假如我们自己开发一个播放器，播放器有播放功能、拖拽进度条功能、停止播放功能、暂停播放功能，我们自己去操作播放器的时候并不是直接调用播放器的方法，而是通过一个控制条去传达指令给播放器内核，那么具体传达什么指令，会被封装为一个个的按钮。那么每个按钮就相当于是对一条命令的封装。用控制条实现了用户发送指令与播放器内核接收指令的解耦。

// Receiver角色：播放器内核GPlayer
public class GPlayer {
   
    public void play(){
   
        System.out.println("正常播放");
    }

    public void speed(){
   
        System.out.println("拖动进度条");
    }

    public void stop(){
   
        System.out.println("停止播放");
    }

    public void pause(