意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
主要解决：主要解决接口选择的问题。
何时使用：我们明确地计划不同条件下创建不同实例时。
如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。
工厂模式分类
工厂模式种类分为三类：
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打开类图，观察类的继承关系，如下图所示
