前言
上一個文章介紹了如何學習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設計中最應當掌握的初級模式。
如果上文對您有所幫助，或有不當的地方，可留言探討。忙碌工作之余，碼字不易，期待大家的互動與鼓勵~