命令模式详解、命令模式怎么用、命令模式模板代码

文章目录

• • @[toc]
  • 1.背景前言
  • 2.命令模式
  • • 2.1 命令模式概念
    • 2.2 命令模式角色
    • 2.3 命令模式分析
    • 2.4 命令模式的优点
    • 2.5 命令模式的缺点

1.背景前言

传统的OO思维：

设计一个家庭控制软件，可以通过遥控器来控制各个家具。

现有一个空调，那么遥控器接口大致为：

OnOrOffButton方法 ----- 开关接口负责控制开或关，

Control方法 ------ 升降接口负责控制温度升高或降低

Switch方法 ------ 模式接口负责切换空调的模式切换。

代码写好了。

这时候来了一个新需求，家里买了一个智能音响。

那么代码除了需要添加一个针对智能音响的类，还需要对上面三种方法进行修改，添加智能音响的属性以及功能实现。

那么如果家里买了一堆堆的智能家具，那么这个代码就要重复n多遍已完成对所有智能家具的控制。很明显，这样虽然功能是能实现，但是再扩展性和维护性上就不好了。整体的开发效率也相对低很多。

通过仔细观察，可以发现所有的方法其实是通过遥控器来实现调用的（物联网下，一个控制器可以控制多个设备，例如小米家庭那个软件），遥控器是通过命令将指令发送出去，完成功能实现。

这时候，当遇到需要通过命令来处理各个请求的时候，命令模式就登场了！

2.命令模式

2.1 命令模式概念

百度百科：在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern）。

2.2 命令模式角色

1、Command：命令 ----- 为所有命令声明了一个接口，或者把命令封装成一个抽象类，每一个命令都是一个对象。调用命令对象的 execute()方法，就可以让接收者进行相关的操作。这个接口也具备一个 undo() 方法。注意标黑，所有命令！

----->>Command也可以定义成类，在Command里面可以把具体的一些接收者声明一下，这样在后面具体命令类中，就可以直接

public abstract class Command {
    //定义具体命令最终的对象类（其实就是下面会提到的接受者），这样Command的子类就可以直接调用了，说白了，就是把能接受命令的对象生命在这里。发布命令的时候就可以直接一步到位了
    protected AirCondition ac = new AirCondition();
    protected Stereo sto = new Stereo();
    
    public abstract void execute(); //执行命令
    public abstract void undo();    //撤销命令
}

2、ConcreteCommand：具体命令 ----- 实现命令接口，定义了动作和接收者之间的绑定关系。调用者只要调用 execute() 就可以发出请求，然后由 ConcreteCommand 调用接收者的一个或多个动作。

----->>这里的ConcreteCommand其实就是具体的命令啦，比如AirConditionOnCommand来控制空调开启和关闭的命令。StereoOnCommand来控制智能音响的开启和关闭命令。客户的任何新需求都可通过增加一个具体的Command子类，实现一个具体命令。每一个命令都将封装起来。在这里才真正的定义了命令与接收者的关系，在高层是看不到命令对应的接收者是谁，也不关心。

public class StereoOnCommand extends Command {
    /**
     * 重写Command命令类的方法
     */
    @Override
    public void execute() {
        //当然，在这里也可以调用其他在command中声明的接收者，进行组合完成执行命令
        super.sto.on();
    }
    @Override
    public void undo() {
        super.sto.off();
    }
}

3、Invoker：请求者 ----- 持有一个命令对象，有一个行动方法，在某个时间点调用命令对象的 execute() 方法，将请求付诸实行。

----->>这里的Invoker其实就是具体的命令请求方，有点想MVC里的controller用来做总控制，比如RemoteInvoker来作为控制智能家店的命令发起方（即命令的请求者），然后通过上面的Command来请求对应的具体命令，比如控制空调的AirConditionOnCommand或控制音响的StereoOnCommand，最终指向对应的接收者。但是千万不要以为请求者和接收者之间有什么关系！请求方不关心接收方是谁，接收方怎么实现的，实现了没有，什么时候实现的。。。等等都不关心。这也是命令模式的魅力，将发起与接收的耦合降到最低，大大提高了扩展性！

更形象一点的举个例子，一个团队负责开发一个项目，这个项目中只需要出一个人和客户接口，客户也只对这一个接口人提出项目要求。具体项目内如何开发，如何运转，如何实现，客户并不关心，客户只对接口人输出信息。而接口人反过来对项目则按需安排工作，这个接口人就是Invoker，而客户就是下面提到的client。

public class Invoker {
    private Command command
    //客户发出命令
    public void setCommond() {
        this.command = command;
    }
    //执行客户命令
    public void action(){
        this.command.execute();
    }

}

4、Receiver：接收者 ----- 接收者知道如何进行必要的动作，实现这个请求。任何类都可以当接收者。

----->>这里的Receiver就对应的命令落地方，接收方，接收命令的那个实体。比如空调AirCondition或者音响Stereo

//父类Receiver是个抽象类，所有接受者都是该抽象类的子类，为所有接收者的抽象集合
public class Stereo extends Receiver{

    public void on() {
        System.out.println("开启音响");
    }
    public void off() {
        System.out.println("关闭音响");
    }
}

5、Client：客户端 ----- 创建一个具体命令(ConcreteCommand)对象并确定其接收者，包括把其他角色串连在一起。

----->>其实看到这里，就会发现，前面的接受者，请求者，命令，具体命令之间是松耦合的，是没有耦合关联的，所以，我们需要用客户端Client，来组合这些松耦合的模块行程一套整体的命令流程体系。根据不同的需求，在Client中用不同的命令组合去实现，就将这些分散的小伙伴们聚在了一起！

public class RemoteClient {

    public static void main(String[] args) {
		//先定义接口人，就是请求者Invoker
        Invoker boss = new Invoker();
        //下达命令！
        Command command = new StereoOnCommand();
        //接口人收到命令
        boss.setCommand(command);
        //接口人执行命令
        boss.action();
        //看上面代码就可以发现，如果有不同的命令，只需要改下达命令那里的具体命令对象，其余不用变。
        //这样非常的高效
    }
}

2.3 命令模式分析

百度百科对命令模式的分析非常易懂，非常清晰的指出了命令模式的特点：

1.命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开。

2.每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。

3.命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。

4.命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。

5.命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。

2.4 命令模式的优点

1.降低对象之间的耦合度。

2.新的命令可以很容易地加入到系统中，可扩展性非常高！

3.可以比较容易地设计一个组合命令。命令都是对象，组合起来非常方便

4.和其他模式结合可以变得更加好用！

2.5 命令模式的缺点

其实看到这里了，你肯定会有一个疑问，如果窝家里有100个智能家电，平均每个家电都有6个命令，那就会有至少600个命令对象，这将是非常庞大的command类群。当然可以结合模板方法模式来减少command子类膨胀，但依旧需要谨慎使用~