设计模式——命令模式实战之前奏（一）

设计模式中的命令模式属于行为模式，命令模式的本质是 “将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。”

本系列文章会基于实践场景进行抽象，然后重构，并分析每次代码架构升级的目标以及带来的利弊。

背景

WCS，仓库控制系统，主要任务就是接受WMS产生的任务，然后下发给相关的硬件，让硬件在仓库内执行命令。主要就是出入库等之类的任务。系统的控制流转图，如下：

需求

非行业内的同学，可能仓库内的操作流程不熟悉，简单对库内的整体流程进行了抽象了一下，如图：

图中的橙色部分为WMS能力，绿色部分为WCS能力。

WCS需求

WMS为已有系统，也不在本次实践范围内，不过多介绍。重点分析一下WCS的核心逻辑。把WCS的核心逻辑进行抽象后，如图：

在实际业务场景中还需要关注硬件的健康状态，工作线程的健康状态

1. WCS主动监听是否有任务
2. 如果发现有任务就读取任务
3. 将读取到的任务转换为硬件执行命令，具体的任务和命令数据结构就不多描述了偏向于业务了
4. 反馈任务执行状态给WMS

第一版实现的代码逻辑，比较简单粗暴，核心类如下：

public abstract class HardwareMasterRunnable implements Runnable{} 
public abstract class HardwareRunnable implements Runnable{} 
public class HardwareServer{}
public class HardwareProtocol{}
public abstract class StackerCallable implements Callable<Boolean>{}

HardwareMasterRunnable： 异步执行的抽象，负责周期性的调度不同硬件的线程。
HardwareRunnable: 硬件线程抽象类，负责控制硬件的工作。
HardwareServer： 负责硬件的控制，命令的执行以及状态的抓取。
HardwareProtocol： 负责硬件之间的任务衔接，自动执行下一条命令。
HardwareCallable： 硬件命令执行抽象线程，需要异步获取返回值。

通过这几个类实现了出版的硬件控制，命令执行结果获取，硬件状态监听。

实现分析

第一版的实现是跟着业务的任务流，以及命令流，一站到底的实现的。中间对于异步进行了一定的关注。这种代码遇到需求或者流程的变动，需要深入代码过程去修改调整。

优势

要说优势的话，可能就是对开发人员要求不高，会点线程，明白业务流，会看硬件接口就行。

缺点

1. 代码平铺之下，维护难度高
2. 不容易扩展，有需求改动，需要完全了解代码
3. 出现BUG，排查难度大