荣小菜补钙记第5期：基于LabVIEW OOP的仪表控制库(2)

大家好，我是荣小菜，也可以叫我Richie，今天继续分享基于LabVIEW OOP的仪表控制库系列。上一期中我们完成了底层驱动库，可以根据仪表信息，通过相应工厂创建不同仪表，但是仪表创建出来后我们怎么使用呢？具体执行哪个方法呢？

可以肯定的是，我们需要指定执行哪个方法(如打开RF、设置频率等)。看到这里我们可以发现“执行什么方法”是变化的不确定的，因此我们要将这种变化封装，这里我采用策略模式。

工程树如下：和工厂模式类似(所以就不画UML类图啦)，只是这次是对方法(算法)的封装。首先建立抽象父类“信号源_方法”，随后建立一些列具体子方法“信号源_打开RF”、”信号源_设频率”等，再建立方法工厂来负责创建方法。

如下图所示，Creator依旧采用映射技术，通过输入“动作”字符串来创建具体类。

比如输入“设置RF开关”，则创建“信号源_设RF开关”具体方法类。与一般的Creator不通的是，“信号源抽象方法”类变成了输入端，这样方便将抽象类中的一些数据传递给具体类。因为经过类型转换后原类的数据无法自动传递给转换后的类。此处不再多说，后续会用到该输入端。

需要注意的是，因为我们是对仪表所含的方法(算法)的封装，因此信号源_方法类仅包含“Do”这一个方法即可，也即只负责“执行”信号源的动作。这也就出现了一个大问题，不同仪表的动作，是有不同的输入数据的，比如“打开RF”和“设置频率”两种动作一个需要Bool输入，一个需要DBL输入，怎么能共用一个“Do”函数的输入端口呢？

还记得上期的伏笔吗，我们从一开使“偷懒”用了“变体”，我们这里继续使用变体作为输入输出，这样就可以使“打开RF”和“设置频率”等动作共用一个”Do”函数了，因为输入输出端口都可以是变体。这样我们的“信号源_方法“类无需关心输入数据是什么，只要负责传递到对应具体方法即可。

到这一步里，其实我们只需要让“信号源_方法”类中包含“信号源”抽象类就可以调用信号源的底层驱动库了。

我们看一个具体类“信号源_设置RF开关”来作为范例，看看是如何完成调用的，它的“Do”方法如下图所示，从父类中读取“TCP链接”和“信号源”，再调用“打开RF”抽象方法。只要信号源指定了，就可以执行到具体的“打开RF”，如信号源为SMF100A，则执行SMF100A的“打开RF”。

根据上述我们可以照葫芦画瓢继续完善频谱仪、示波器等仪表的方法类封装。如果仪表种类

更多，完全可以再抽象一层，建立“仪表_方法“抽象父类。不过我没有这么做，因为它们还会被更高层”策略层“掉用，这后续会讲到。

在这一期里我们通过策略模式把“执行什么动作“进行了封装，使用”Do“方法调用调用不同的仪表动作，完成了对底层驱动的调用。到了这一步我们已经完成了”底层“设计(包含底层驱动)。细心的同学会发现，上一期讲的用来创建仪表的工厂类和本期的工厂类其实均没有被调用。这是因为我们的“底层”设计其实总体上就包含两个任务，一个是“创建一个仪表”，一个是“执行一个动作”，这两期其实我们是将这两种职责完成了，下一期我们将进入”中层“设计-“策略”类的开发，在中层调用这两个任务。