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个,这样这个类就会变得非常庞大,这时候就需要慎重考虑使用,具体情况可以结合其他的设计模式进行优化的。