前言
上一个文章介绍了如何学习LabVIEW OOP，简要的提及了一些OOP学习中注意的事项，许多文章的读者反映写的太范，后文会逐步缩小范围，讨论在LabVIEW中各个模式的应用。
工厂模式概述
工厂模式属于创建型模式，它是面向对象实例化时候的一种最佳方式。在这种模式中，我们创建对象不会对客户端暴露创建逻辑，通过一个共同的接口来指向新创建的对象。
意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
主要解决：主要解决接口选择的问题。
何时使用：我们明确地计划不同条件下创建不同实例时。
如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。
工厂模式分类
工厂模式种类分为三类：
1. 简单工厂模式
2. 工厂方法模式
3. 抽象工厂模式
上述模式从上到下逐步抽象，GOF在《设计模式》中将简单工厂归为工厂方法的简化版本，而实际使用中，尤其是LabVIEW程序开发，简单工厂模式更加容易理解和应用，所以本文以简单工厂模式介绍，后续文章在逐渐分析其他模式。
简单工厂模式
简单工厂主要由3部分组成：
1.工厂类角色：这是本模式的核心，是一组控制逻辑（LabVIEW中此处可以不以类的形式出现）
2.抽象产品角色：它一般用来定义产品的特性
3.具体产品角色：用来具体做某些事情
下图为简单工厂的UML
Abstract Product 为抽象的产品，用来定义产品的特性
Product1-3 分别继承Abstract Product的特性和方法，将具体的执行下放到子类中
Creator 起到了工厂类的作用，用于指定生成产品的方法和逻辑
LabVIEW中的简单工厂
为什么用简单工厂模式
简单工厂应用于小黑的LabVIEW程序编写起源于一个客户需求。在项目进行中，客户要求使用一套统一的API去控制不同种类的的电源设备，而这些电源种类各异，指令各不相同。如果是传统的LabVIEW编程，你会如何做呢？
在面向过程的程序编写中，我们往往会设计顶层的子VI，然后使用Case结构，将类似的VISA控制指令写入多个VI
这种写法在无设备拓展性要求时，可以很快Cover用户需求，但客户一旦增加一种设备的驱动，则需要增加自定义枚举，并且在每一个方法中修改Case结构。这种写法可以完成目的，但是将多个驱动耦合到一起，无论是增加，删除，还是单独调试都非常不便。
此时，使用简单工厂模式即可快速解决传统写法的不足，既可以实现快速的拓展，也可以实现不同驱动的解耦。在面向对象程序设计时，第一步进行UML图绘制
抽象类 Abstract Power用于定义客户需要的通用接口，在与客户讨论的时候，你可以重点关系客户需要如何使用这些API，需要哪些控制参数，而完全不必了解具体哪个电源如何实现。
当设计某一个电源的控制方法时，可以继承父类，并且直接重写各个需要的方法，而不必关心要给客户留哪些接口。
在调用这些API的时候，统一使用抽象的接口，通过枚举或者其他方法控制初始化执行哪个子类。通过这种程序设计，将产品的实际执行下放到类子类中。
如果需要拓展驱动（如这里创建了一个TestPower），可以直接继承并且重写方法，由父类直接获得所有接口和设计
驱动完成拓展后，主程序基本不进行改动
在初始化驱动的时候，增加选择器，根据配置初始化不同的驱动即可
LabVIEW报表工具包
LabVIEW其实已经给出了简单工厂模式的一个最佳范例，它就是LabVIEW的报表生成工具包
报表工具包的顶层给出了一些通用的报表功能，如初始化，打印报表，保存报表，通过工厂模式，设计抽象的产品NI Report来定义报表创建过程中常用到的功能
在LabVIEW中可以通过LabVIEW Class Hierarchy打开类图，观察类的继承关系，如下图所示
在初始化的工厂中（这里是最上层的API），通过枚举来控制初始化不同的驱动
如果后续拓展报表工具包的代码，同样只需要继承父类的方法，然后修改初始化的Case即可
后记
上文的分析可以看出，简单工厂模式的引入为代码的可拓展性提供的更好的解决方法，这种模式是面向对象程序设计中最基本的设计模式，也是LabVIEW设计中最应当掌握的初级模式。
如果上文对您有所帮助，或有不当的地方，可留言探讨。忙碌工作之余，码字不易，期待大家的互动与鼓励~