前言
在之前的文章提到了如何学习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设计文章，并且借用商城打折的例子，设计了基于简单工厂的程序，通过对策略的分析，了解了简单工厂和策略模式的联合设计。最后使用开闭原则，将程序的改动仅仅停留在了控件的变更，实现了代码的可拓展和可维护。
后记
感谢大家这么长时间的关注，也谢谢各位的打赏和认可。接下来的一段时间，小黑将要忙自己的婚姻大事去啦，期间的一些学习内容将会在结婚后更新，希望大家多多支持~