设计模式——命令模式实战之WCS概要设计(二)

命令模式实践之前奏

在上一篇命令模式实践前奏篇中对业务场景进行描述，对业务需求进行了抽象的分析，并简述了第一版的实现。接下来使用设计模式中的思想对硬件控制模块进行重构，目标是达到易扩展，便于维护。

总体设计

也可能算作详细设计吧

基于上一篇的场景和需求的分析，对整个硬件控制过程可以抽象为以下部分：

1. 读取任务
2. 识别任务
3. 转为命令
4. 下发到硬件
5. 反馈命令结果
6. 反馈任务结果

过程中需要记录关键日志以及审计日志。

读取任务

任务获取可以分为两种形式：主动获取、被动获取。差异点体现如下：

-	主动获取	被动获取
特点	自主调度 识别自身压力	实现逻辑简单 需要识别自身压力，并反馈到外部

在这里，重构过程中通过被动方式实现，代码对外提供任务读取接口，需要外部业务方实现接口，共WCS内部调度读取。接口代码如下：

public interface TaskPicker {
    public List<Task> take();
}

任务类图如下：

识别任务

识别任务主要职责是需要根据读取到的任务分配判断有具体哪些硬件来执行，以及任务的相关业务参数，如货物尺寸，位置等。列一下核心字段作用：

字段	描述
taskStage	任务阶段，可以判断交给什么硬件执行
taskCate	任务分类，判断硬件对于此任务执行什么操作

类签名如下：

public class HardwareTask {
    // 任务阶段
    private int taskStage;
	// 任务类型
	private int taskCate;
}

还有其他的字段就是标识任务的业务属性了。类图如下：

转换命令

读取到任务之后，需要转为硬件可以识别的命令，然后下发给硬件，让硬件执行命令。就像编程一样，写好的程序要想让计算机执行，必须转为计算机可以明白的命令，然后执行。命令类如下：

public class TaskCommand implements Command{
	private String cmd;
	private Function<Result,Boolean> callback;
	private HardwareTask task;
	private Hardware hardware;
	public void execute(){
		hardware.action(cmd,task,callback);
	}
}

代码中是集成了硬件类的，可以对命令直接执行，调用的过程中会将命令以及任务参数下发给硬件，需要异步监听硬件的执行过程然后返回命令状态，最后回调任务回调方法。

callback方法就是，读取任务的时候，直接传进来的回调方法。在回调方法中，业务可以自行选择更新数据库或者缓存等。

整体实现的类结构如下：

• Command：是众所周知的，命令的抽象
• TaskCmd：是具体命令的实现
• HardwareReciver：是真正连接硬件，下发命令的类，可以理解为硬件服务类
• Invoker：调用者，可以理解为是收集命令的一个类，命令在这个类中放入队列，等待一条一条被执行。
• HardwareClient：是硬件和命令的整体调度端，需要完成，硬件的监听，命令的转换，任务的提取等动作的调度。

本文就先简单介绍到这里，下一篇更具体的介绍实现。