行为型-命令模式 Link to heading

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

模式结构 Link to heading

Command：

定义命令的接口，声明执行的方法。

ConcreteCommand：

命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

Receiver：

接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

Invoker：

要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

Client：

创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。

场景模拟 Link to heading

比如现在我们有很多的类，彩电、冰箱、空调、洗衣机、热水器等，既然现在我们要通过一个遥控器去控制他们，那么我们就需要将控制这些电器的指令都给设计好才行，并且还不能有太强的关联性。

所有的电器肯定需要通过蓝牙或是红外线接受遥控器发送的请求，所以所有的电器都是接收者：

public interface Receiver {
    void action();   //具体行为，这里就写一个算了
}

接着我们要控制这些电器，那么肯定需要一个指令才能控制：

public abstract class Command {   //指令抽象，不同的电器有指令

    private final Receiver receiver;

    protected Command(Receiver receiver){   //指定此命令对应的电器（接受者）
        this.receiver = receiver;
    }

    public void execute() {
        receiver.action();   //执行命令，实际上就是让接收者开始干活
    }
}

最后我们来安排一个遥控器：

public class Controller {   //遥控器只需要把我们的指令发出去就行了
    public static void call(Command command){
        command.execute();
    }
}

比如现在我们创建一个空调，那么它就是作为我们命令的接收者：

public class AirConditioner implements Receiver{
    @Override
    public void action() {
        System.out.println("空调已开启，呼呼呼");
    }
}

现在我们创建一个开启空调的命令：

public class OpenCommand extends Command {
    public OpenCommand(AirConditioner airConditioner) {
        super(airConditioner);
    }
}

最后我们只需要通过遥控器发送出去就可以了：

public static void main(String[] args) {
    AirConditioner airConditioner = new AirConditioner();   //先创建一个空调
    Controller.call(new OpenCommand(airConditioner));   //直接通过遥控器来发送空调开启命令
}

通过这种方式，遥控器这个角色并不需要知道具体会执行什么，只需要发送命令即可，遥控器和电器的关联性就不再那么强了。