设计模式—— 十五 :命令模式

文章目录

什么是命令模式?

命令模式的定义:

Encapsulate a request as an object,thereby letting you parameterize clients with different requests,queue or log requests,and support undoable operations.(将一个请求封装成一个对象,从而让你使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能。)

命令模式的核心在于引入了命令类,通过命令类来降低发送者和接收者的耦合度,请求发送 者只需指定一个命令对象,再通过命令对象来调用请求接收者的处理方法。

命令模式通用类图如下:

图15-1:命令模式模式通用类图

设计模式—— 十五 :命令模式

命令模式包含这么几个角色:

  • Command(抽象命令):声明需要执行的命令
  • ConcreteCommand(具体命令):实现声明的命令
  • Receive(接收者):接收者执行与请求相关的操作,它具体实现对请求的业务处理
  • Invoker(调用者):调用者即请求发送者,它通过命令对象来执行请求。

命令模式的本质是对请求进行封装,一个请求对应于一个命令,将发出命令的责任和执行命令的责任分割开。每一个命令都是一个操作:请求的一方发出请求要求执行一个操作;接收的一方收到请求,并执行相应的操作。命令模式允许请求的一方和接收的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求如何被接收、操作是否被执行、何时被执行,以及是怎么被执行的。

命令模式通用代码如下:

  • Receiver:Receiver类实现具体的业务需求
/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 接收者
 */
public class Receiver {
    public void doSomething() {
        //具体的业务逻辑
    }
}
  • 抽象的Command类:
/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 抽象的Command类
 */
public abstract class Command {
    // 每个命令类都必须有一个执行命令的方法
    public abstract void execute();
}
  • 具体的Command类:根据需求,具体的命令类可以有多个:
/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 具体的命令类
 */
public class ConcreteCommand extends Command {
    // 维持一个对请求接收者对象的引用
    private Receiver receiver; 

    //构造函数传递接收者
    public ConcreteCommand(Receiver receiver) {
        this.receiver = receiver;
    }

    public void execute() {
         // 调用请求接收者的业务处理方法doSomething()
        receiver.doSomething();
    }
}
  • 调用者Invoker类:
/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 调用者
 */
public class Invoker {
    private Command command;
    
    // 设值注入
    public void setCommand(Command command) {
        this.command = command;
    }

    // 执行命令
    public void action() {
        this.command.execute();
    }
}
  • 场景类:
/**
 * @author 三分恶
 * @date 2020年6月28日 
 * @description  
 */
public class Client {

    public static void main(String[] args) {
        //首先声明调用者Invoker 
        Invoker invoker = new Invoker(); 
        //定义接收者 
        Receiver receiver = new Receiver(); 
        //定义一个发送给接收者的命令 
        Command command = new ConcreteCommand(receiver); 
        //把命令交给调用者去执行 
        invoker.setCommand(command); 
        invoker.action();
    }

}

为什么要用命令模式?

假设有一个这样的业务场景:一个正在开发的软件项目,分为三个组:需求组、美工组、开发组。在开发的过程中,客户需要和厂商沟通,和需求组讨论需求、和 美工讨论页面、和代码组讨论实现,告诉他们修改、删除、增加各种内容等。

使用命令模式前

上面的业务场景抽象成类图:

图15-2:甲方要求业务场景初始类图

设计模式—— 十五 :命令模式

根据类图进行具体的编码实现:

  • Group:抽象类,定义业务:
/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 抽象Group
 */
public abstract class Group {
    // 甲乙双方分开办公,如果甲方要和某个组讨论,首先要找到这个组
    public abstract void find();

    // 要求增加功能
    public abstract void add();

    // 要求删除功能
    public abstract void delete();

    // 要求修改功能
    public abstract void change();

    // 要求给出所有的变更计划
    public abstract void plan();
}
  • RequirementGroup(需求组):
public class RequirementGroup extends Group{

    @Override
    public void find() {
        System.out.println("找到需求组...");
    }

    @Override
    public void add() {
        System.out.println("客户要求增加一项需求...");
    }

    @Override
    public void delete() {
        System.out.println("客户要求删除一项需求...");
    }

    @Override
    public void change() {
        System.out.println("客户要求修改一项需求...");
    }

    @Override
    public void plan() {
        System.out.println("客户要求需求变更计划...");
    }

}
  • PageGroup(美工组):
public class PageGroup extends Group{

    @Override
    public void find() {
        System.out.println("找到美工组...");
    }

    @Override
    public void add() {
        System.out.println("客户要求增加一个页面...");
    }

    @Override
    public void delete() {
        System.out.println("客户要求删除一个页面...");
    }

    @Override
    public void change() {
        System.out.println("客户要求改变一个页面...");
    }

    @Override
    public void plan() {
        System.out.println("客户要求页面变更计划...");
    }

}
  • CodeGroup(开发组):
public class CodeGroup extends Group{

    @Override
    public void find() {
        System.out.println("找到代码组...");
    }

    @Override
    public void add() {
        System.out.println("客户要求增加一项功能...");
    }

    @Override
    public void delete() {
        System.out.println("客户要求删除一项功能...");
    }

    @Override
    public void change() {
        System.out.println("客户要求修改一项功能...");
    }

    @Override
    public void plan() {
        System.out.println("客户要求代码变更计划...");
    }

}
  • 场景类:
public class Client {

    /**
     * @param args
     */
    public static void main(String[] args) {
        //首先客户找到需求组说,过来谈需求,并修改
        System.out.println("-----------客户要求增加一项需求---------------"); 
        Group rg = new RequirementGroup();
        //找到需求组
        rg.find(); 
        //增加一个需求 
        rg.add(); 
        //要求变更计划 
        rg.plan();
    }

}

运行结果:

设计模式—— 十五 :命令模式

场景类中客户找到了需求组,向需求组提出了增加需求和需求变更的要求。

这样存在什么问题呢?甲方对乙方做一些要求的时候,要找到对应的组,但是不能希望甲方是非常专业的,可能提需求提到了开发组头上,要求页面变更提到了需求组头上。

使用命令模式后

这是为什么项目需要项目经理的原因之一。

甲方不管你什么需求、美工、开发,只管把项目经理叫过去,告诉项目经理他们的要求。项目经理再根据甲方的要求向各个组下达命令。对应的,就可以引入命令模式。

图15-3:甲方要求业务场景引入命令模式的类图

设计模式—— 十五 :命令模式

来看看具体的代码:

  • 抽象命令类:
public abstract  class Command {
    //把三个组都定义好,子类可以直接使用 
    protected RequirementGroup rg = new RequirementGroup();   //需求组
    protected PageGroup pg = new PageGroup(); //美工组 
    protected CodeGroup cg = new CodeGroup(); //代码组 
    //只有一个方法,你要我做什么事情 
    public abstract void execute();
}
  • 增加需求的命令:
public class AddRequirementCommand extends Command{

    @Override
    public void execute() {
        //找到需求组 
        super.rg.find(); 
        //增加一份需求
        super.rg.add(); 
        //给出计划 
        super.rg.plan();
    }

}
  • 删除页面的命令:
public class DeletePageCommand extends Command{

    @Override
    public void execute() {
        //找到页面组 
        super.pg.find(); 
        //删除一个页面 
        super.rg.delete();
        //给出计划 
        super.rg.plan();
    }

}
  • 负责人Invoker:负责人只要接到客户的命令,就立刻执行。
public class Invoker {
    // 什么命令
    private Command command;

    // 客户发出命令
    public void setCommand(Command command) {
        this.command = command;
    }

    // 执行客户的命令
    public void action() {
        this.command.execute();
    }
}
  • 场景类:模拟客户增加需求的命令。
public class Client {
    public static void main(String[] args) {
        // 定义调用者
        Invoker jingli = new Invoker();
        // 客户要求增加一项需求
        System.out.println("------------客户要求增加一项需求---------------");
        // 客户下命令
        Command command = new AddRequirementCommand();
        // 调用者接收到命令
        jingli.setCommand(command);
        // 调用者执行命令
        jingli.action();
    }
}

场景类就简单了很多,如果客户提出其它要求,如删除页面,只需要:

// 客户下命令
//Command command = new AddRequirementCommand();
Command command = new DeletePageCommand();

同样比较简单。

这样一来,客户提要求的时候,不需要知道具体谁去完成这个要求,只需求把这个要求提给项目经理即可。

高内聚的要求就被满足了。

命令模式优缺点

优点

● 类间解耦

调用者角色与接收者角色之间没有任何依赖关系,调用者实现功能时只需调用Command 抽象类的execute方法就可以,不需要了解到底是哪个接收者执行。

● 可扩展性 Command的子类可以非常容易地扩展,而调用者Invoker和高层次的模块Client不产生严 重的代码耦合。

缺点

使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个对请求接收者的调 用操作都需要设计一个具体命令类,因此在某些系统中可能需要提供大量的具体命令类,这 将影响命令模式的使用。

命令模式使用场景

在以下情况下可以考虑使用命令模式:

  • 系统需要将请求调用者和请求接收者解耦,使得调用者和接收者不直接交互。请求调用者 无须知道接收者的存在,也无须知道接收者是谁,接收者也无须关心何时被调用。
  • 系统需要在不同的时间指定请求、将请求排队和执行请求。一个命令对象和请求的初始调 用者可以有不同的生命期,换言之,最初的请求发出者可能已经不在了,而命令对象本身仍 然是活动的,可以通过该命令对象去调用请求接收者,而无须关心请求调用者的存在性,可 以通过请求日志文件等机制来具体实现。
  • 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。


上一篇:【web前端优化之图片模糊到清晰】看我QQ空间如何显示相片


下一篇:【自然框架】 页面里的父类—— 改进和想法、解释