23种设计模式9_命令模式

23种设计模式9_命令模式

1 基本介绍

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

UML类图如下：

从类图种可以看出，有三种角色：

Invoker调用者 协调调用命令，什么命令由谁来执行。

Command命令 命令角色，需要执行的命令的详细内容都封装在命令角色里面。

Receiver接收者 这个角色就是命令内容的具体的干活的人。

2 通用代码演示

Receiver调用者

public abstract class Receiver {
    public abstract void opt();
}

// 接收者的具体实现可以有多个
public class ConcreteReceiver extends Receiver{
    @Override
    public void opt() {
        System.out.println("业务逻辑处理。。。。");
    }
}

Command命令

public abstract class Command {
    public abstract void exec();
}

// 命令也可以有很多具体实现
public class ConcreteCommand extends Command {
    private Receiver receiver;

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

    @Override
    public void exec() {
        receiver.opt();
    }
}

Invoker调用者

public class Invoker {
    private Command command;

    public void setCommand(Command command) {
        this.command = command;
    }

    public void call() {
        command.exec();
    }
}

main方法演示

public static void main(String[] args) {
    Invoker invoker = new Invoker();

    Receiver receiver = new ConcreteReceiver();

    Command command = new ConcreteCommand(receiver);

    invoker.setCommand(command);
    invoker.call();
}

3 案例演示

需求：客户需要开发程序，联系公司的项目负责人，发布程序的需求，项目负责人再根据需求将具体的业务分发给各个岗位上的工作人员（程序开发、UI设计、软件测试等等）。

先增加三个岗位的工作人员，即Receiver角色：

public abstract class Worker {
    public abstract void work();
}

// 开发人员
public class Coder extends Worker{
    @Override
    public void work() {
        System.out.println("code...............");
    }
}

// UI设计
public class Designer extends Worker{
    @Override
    public void work() {
        System.out.println("design..............");
    }
}

// 测试人员
public class Tester extends Worker{
    @Override
    public void work() {
        System.out.println("test...............");
    }
}

添加需求任务，即Command：

public abstract class Task {
    public abstract void exec();
}

public class CodeTask extends Task {

    private Worker worker;

    public CodeTask(Worker worker) {
        this.worker = worker;
    }

    public void exec() {
        this.worker.work();
    }
}

public class DesignTask extends Task {

    private Worker worker;

    public DesignTask(Worker worker) {
        this.worker = worker;
    }

    public void exec() {
        this.worker.work();
    }

}

public class TestTask extends Task {

    private Worker worker;

    public TestTask(Worker worker) {
        this.worker = worker;
    }

    public void exec() {
        this.worker.work();
    }

}

添加项目经理，即Invoker：

public abstract class Leader {
    private Task task;

    public void setTask(Task task) {
        this.task = task;
    }

    public Task getTask() {
        return task;
    }

    public abstract void projectTask();
}

public class ProjectManager extends Leader{

    @Override
    public void projectTask() {
        getTask().exec();
    }
}

Client模拟演示客户提出需求：

public class Client {
    public static void main(String[] args) {
        // 1.实例化各个岗位的人员:项目经理，开发人员，UI设计，测试人员。
        Leader projectManager = new ProjectManager();
        Worker coder = new Coder();
        Worker designer = new Designer();
        Worker tester = new Tester();

        // 2.项目经理收到客户发来的需求，并将这个需求整理成各个岗位需要完成的任务。
        Task codeTask = new CodeTask(coder);
        Task designTask = new DesignTask(designer);
        Task testTask = new TestTask(tester);

        // 3.项目经理布置需求任务，各个岗位的工作人员执行对应的任务。
        projectManager.setTask(designTask);
        projectManager.projectTask();
        projectManager.setTask(codeTask);
        projectManager.projectTask();
        projectManager.setTask(testTask);
        projectManager.projectTask();
    }
}

运行演示结果如下：

4 案例拓展

① 上面案例演示的代码比较简单，包括一些逻辑处理的我都是简单化的，实际业务中可以根据具体的业务情况完善业务执行方法的。还可以根据不同的任务设计多种任务接口，这样拓展就很方便了。

② 实际应用中会存在这种情况（反悔问题）：比如说客户说了一个需求，然后工作人员根据需求也完成的差不多了，这时候客户说这个需求不需要了，需要撤回到上一个状态。这在实际开发中是经常出现的，这种情况可以结合日志和业务逻辑设计对应的回滚rollback的放方法。

③ 演示的案例中，通过Client模拟用户提出的需求，根据约定高于配置的原则，命令Command中应该对一个或者多个接收者Receiver进行封装，这样降低命令处理角色和命令接收者角色之间的耦合关系，减少高层模块对底层模块的依赖关系，提高系统稳定性。

5 优缺点分析

优点：

①解耦。命令中对接收者进行封装，这样调用者角色和接收者角色之间不存在依赖关系，具体也不需要关系接收者是谁。

②可扩展性。命令类Command的子类可以非常容易地扩展，对调用者或者程序高层模块不存在影响。

缺点：

缺点也是非常明显的，如果业务逻辑比较复杂，可能命令类Command的子类会有N个，这样这个类就会变得非常庞大，这时候就需要慎重考虑使用，具体情况可以结合其他的设计模式进行优化的。