【LabVIEW技巧】策略模式

前言

在之前的文章提到了如何学习OOP以及对应的简单工厂模式，由于时间比较长，我们先回顾一下原有内容，然后继续了解新的模式。

为什么学习OOP

在测控系统的软件开发过程中，LabVIEW工程师一直认为程序完成功能就可以了，但是随着程序越来越复杂，渐渐发现很多情况下成型系统到后期无法添加功能或很难添加功能。

是什么阻碍了软件系统的开发？为什么在需求沟通不明确的前期，我们无法开发软件；在需求明确的后期，又难以对软件进行灵活修改。

与软件维护类似的情况最先出现在刻板应刷中，那时的古人一旦设计完成系统，将祈求不再变更。因为一旦变更，其代价就会非常大，需要重新制版印刷，如果连续变更就会意味着连续的修改刻板，带来了人力和物料的大量浪费

 但是，聪明的中国人，将每一个字都做一个小的刻板，印刷系统将会变为如下的例子

通过某些小模块的替换，可以让印刷更加灵活多变，这种思想的转变也就是活字印刷的成功。

在软件设计的过程中，“活字印刷”术即对应着常见的面向对象思想。通过单一职责原则，OOP可以将系统分割为功能单一的很多小模块，通过小模块的拼接、组织形成不同的程序。一旦任何一处的模块发生了变化，我们只需修改固定的一些模块，即可让系统发生变化。

在软件设计的历史上，OOP的出现也引发了一场设计的革命，这也是我们不得不学习OOP思想的重要原因。

简单工厂模式

既然了解了OOP思想，那OOP的第一个使用方法莫过于简单工厂模式。

通常，在传统的面向过程设计中，使用Case结构来解决不同情况的出现

 

但是当多个函数中都需要进行判断时，Case结构将会写很多个，并且每一次维护代码均需要了解之前的设计，极易造成误修改。

为此，简单工厂模式出现，实现了程序设计的简化。

了解UML类图，可以发现程序在运行时动态选择执行的内容，通过类的继承，可以实现对原有方法的轻易拓展；改动的时候不影响主程序的原有设计，实现了针对接口而不是实现编程。

策略模式

策略模式的学习，我使用《大话设计模式》的例子，做一个深入的了解和熟悉。

该模式的目的是实现一个商场收银软件，通过文本框来输入单价和数量，从而计算输出的结果。

使用传统的方法快速设计，不超过10分钟就完成功能 

当代码完成后，新的需求改动随即而来。商场需要增加打折系统，可以对输出的总价进行不同程度的打折。于是，程序增加打折功选项，支持不打折和打不同折操作，设计完成的代码如下。

当商场需要增加满减活动(如满200减30)时,我们又需要改动程序，增加一个子VI，并且修改程序的连线。

简单工厂实现

为了避免对主程序频繁修改，尝试使用OOP思想对该程序进行改进。

分析程序需求，发现金额计算算法是这段程序中最容易变化的部分，所以对这段算法进行抽象，抽象后的类图如下。

算法抽象

在程序中，我们将变化的部分抽象为AbstractCash，其具有AcceptCash的方法，可以输入当前的金额，并且返回计算后的结果。

 对于采取的商城策略一共有3种类型的处理方式，我们继承抽象并实现这一方法。

对于CashNormal，我们不做任何处理。

 对于CashRebate，可以配置打折比例，并且在运算中对其进行相应的处理

 

CashReturn不同于其他算法，需要增加moneyCondition与moneyReturn两个参数来计算是否执行返现

至此，我们完成了算法的设置，接下来设计工厂类。

工厂设计

此处由于工厂类只有一个方法，也没有属性，所以使用一个子VI来代替类

不打折时，我们使用不打折的类作为输出

 打八折时，我们使用CashRebate作为输出

 设计满减活动时，我们需要使用CashReturn来满足需求

主程序设计

完成设计后，主程序只需要调用抽象的方法即可编写程序

当某一类的方法拓展时，我们只需要在工厂分支中增加一个Case即可，如打7折。除此之外不碰任何的其他程序，实现了程序的快速拓展，而又不影响原有的代码。

 如拓展一个满减活动时，我们同样只改动简单工厂的方法

如拓展一个新的打折活动，如打折积分活动，我们只需要在类图上新增一个继承类，并修改简单工厂即可。

经过试验，整个程序既具有了完善的功能，也实现了特殊变化点的快速拓展。

策略模式实现

简单工厂的程序已经使用到了策略模式的思想，通过抽象运算策略，来实现顶层方法的复用，这里在此基础上，引出策略模式的设计类图。

在策略模式中，我们定义了一个抽象的策略，AbstractCash和3个具体的策略，分别是CashNormal、CashRebate、CashReturn。这里的策略与上文简单工厂中的策略是一样的，不同仅仅在策略模式选择的地方稍有差别。

为了封装策略的变化，使用CashContext聚合AbstractCash，利用GetResult的多态，实现不同策略的替换

在接口设计时，结合简单工厂模式，可以将程序改进为工厂+策略模式

使用策略模式封装后发现，相比于简单工厂模式的例子，

1.在顶层程序完全封装了算法，只需要与给出的预定API交互即可

2.底层的算法变更不会影响主程序的设计，实现了策略的封装和拓展

继续优化代码

策略模式中，我们仍需要每次修改枚举的时候重新编写Case结构。为此，优化工厂的解析策略，可以实现自动初始化特定的类，修改如下

 通过正则表达式，对枚举的规则进行解析，可以实现自动选择正确的执行策略，从而后续的代码修改将只针对于界面上数值的变化。

总结

本文回顾了之前的OOP设计文章，并且借用商城打折的例子，设计了基于简单工厂的程序，通过对策略的分析，了解了简单工厂和策略模式的联合设计。最后使用开闭原则，将程序的改动仅仅停留在了控件的变更，实现了代码的可拓展和可维护。

后记

感谢大家这么长时间的关注，也谢谢各位的打赏和认可。接下来的一段时间，小黑将要忙自己的婚姻大事去啦，期间的一些学习内容将会在结婚后更新，希望大家多多支持~

撒一波狗粮~~~~~

 

null