设计模式-命令模式实战之WCS核心控制重构（四）

基于前面三篇文章背景、分析、设计、实现的铺垫，接下来基于命令行模式对之前的实现进行重构，以及重构过程中需要考虑的问题进行重点分析。

实现原则分析

实现的业务流程是固定，不需要有变化；需要变化的是代码结构，从SOLID原则出发，考虑问题，梳理代码结构，模块关系，数据聚合逻辑。下面是需要关注的问题点：

1. 做全局调度还是做局部调度（每个堆垛机有一个自己的调度器）
2. 队列是放在放在全局调度中心，还是放在堆垛机的实现中

调度器规划

涉及到调度的任务有：堆垛机的监控、工作线程的监控、任务的读取；这三项任务看似是 全局的，有的也可以拆分到具体的堆垛机控制实现中。在上一篇文章的实现中是放在全局进行的，伪代码如下：

scheduledExecutorService.scheduleWithFixedDelay(new Runnable() {
            @Override
            public void run() {
                // 检查堆垛机状态，具体实现参考上一篇文章
                // 启动工作线程
                // 检查工作线程状态，具体实现参考上一篇文章
				// 读取任务
            }
        }, 0, 500, TimeUnit.MILLISECONDS);
    }

可以看到，在全局有一个调度线程池，每隔500毫秒，会全部调度一次。
简单对优缺点进行分析

综合分析下的实现方案：
堆垛机监控： 同步健康命令实现，相当于在全局出发命令生成，在工作线程执行。
工作线程的监控： 放在全局实现，便于保活（发现挂掉，及时拉起）
任务读取： 在全局从数据库读取，并转为命令

队列规划

对于硬件来说一次只能执行一个命令，也就是说命令是串行执行的；这很符合队列结构解决问题的场景。对于硬件的控制来说，软件和硬件都是单独线程进行的。

综合分析的实现方案：
队列属于控制命令流，硬件执行命令的关键通道。从软件架构原则上来说，放在局部堆垛机内更加合适。

问题思考

1.一个任务需要多个硬件配合完成，意味一个任务会生成多个命令，这种场景怎么解决？
2. 对机器控制的记录怎么处理？

WCS控制实现

先看一下实现的类结构：

详细实现

接下来基于命令行模式的情景下 ，对整个实现进行简单的描述。

命令抽象

在前面背景的描述基础下，需要对命令进行抽象；命令的其实是和机器的每个动作是对应的。这样就需要对机器的每个动作进行抽象出共性部分，结合软件实现要求，命令抽象如下：

public interface Command {
   
    public int cmdType();
    public String cmdName();