LabVIEW——北方客栈

2011年，9月8日，第二稿

    什么是设计模式？图形化语言的设计模式会有那些？它对图形化程序的设计会带来那些帮助？

    在许多LabVIEW图形化编程语言的教课书中都谈到了设计模式和设计模式的重要性，那什么是设计模式呢？

    在工程领域，设计模式是一个通用的概念。这里给出软件工程中设计模式的简单定义：

    设计模式——软件设计中，在某情境下，针对某问题的某种解决方案。

• 某情境——就是常常遇到的某种情况，这种情况应该是经常不断的出现。

• 某问题——就是你想在某情境下达到的目标，但也可以是某情境下的约束。

• 某种解决方案——就是你所追求的，一个通用的设计，用来解决约束，达到目标的方法。

    我们在一同再来看看《维基百科》中的解释或说明：
      
    “设计模式这个术语是由Erich Gamma等人在1990年代从建筑设计领域引入到计算机学科的。它是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。
    设计模式并不直接用来完成程序代码的编写，而是描述在各种不同情况下，要怎么解决问题的一种方案。”

    根据上面的种种表述，我们应该对设计模式应该有了一个最基本的了解，并给出设计模式的确切表达方法。
      
    严格地讲，软件中的设计模式是针对某些经常出现的问题而给出的一种行之有效的设计解决方案。设计模式是软件的战术思想，它侧重于设计思想的重用。

    通俗地讲，就是已经有人遇到了你正在经历（或还不曾经历）的问题，并且他们已经成功的解决了这些问题，我们现在可以参考或借见这些现成的方案。

    尽管设计模式被认为是软件设计中的一种战术思想，但针对不同的编程语言，它们的设计模式是不相同的。例如，仅针对Java编程语言OOP的设计模式就多达23种［19］。由此可见，编程语言中的设计模式是多么的重要。

    这里我们再次强调：设计模式是侧重于设计思想的重用，本意是说明设计经验重用的这一基本概念。这些经验来自众多的程序员的实践和验证，并证明它们是行之有效的。

    我们知道：在LabVIEW图形化语言的程序设计中，子VI在概念上也表示出一种强烈的重用特征。但是，这里特别提醒大家注意：子VI所体现的重用仅仅是代码的重用，而并非是设计思想（经验）的重用，所以子VI不是设计模式，而是代码重用的一种方法。

    关于设计模式本身的一些特点，简单总结如下：

• 设计模式是一种设计思想，它应该固化在程序员的大脑之中。

• 设计模式被认为是经过验证的设计经验。

• 设计模式不是被发明的，而是被发现的。

• 设计模式不是程序代码，而是针对设计问题的通用解决方案。

• 应用设计模式，可以确保软件具有良好的质量体系。

    现在，经过对设计模式的了解后，大家更关心、更希望看到的是LabVIEW图形化语言的设计模式都有那些。

    LabVIEW图形化编程语言经过二十五年的发展，已经总结出了许多行之有效的图形化语言的设计模式，并将这些设计模式提供给其它图形化程序设计者使用。下面我们就来初略的认识一下LabVIEW的设计模式。

    打开、运行LabVIEW，在启动界面中可以看到：基于模板的VI...，参见下图。

鼠标点击：基于模板的VI...，
              更多

    在新建窗口下，都可以看到图形化的设计模式，参见下图。

    在上图中，我们可以看到在LabVIEW开发环境中为我们提供了以下的6种图形化语言的设计模式。

标准状态机
队列消息处理器
生产者／消费者设计模式（事件）
生产者／消费者设计模式（数据）
用户界面事件处理器
主／从设计模式

    这些设计模式都是在图形化应用程序设计中比较常见的设计方法。关于这些设计模式的特点的分析和描述我们将在下一节开始进行。

    细心的读者可能会发现，在图9-2中，设计模式是包含在框架的目录下。换句话说，设计模式也是框架中的一种。那什么是框架呢？

    “框架为软件设计构建了一个与特定编程语言相关的、可重用的设计模版，重点在于强调设计上的重用。框架足可以应付复杂的应用软件开发，并确保快速有效。通过框架可以从宏观上控制软件整体的结构和流程。框架内也可能包含多个设计模式。”［3］

    在图9-2中我们可以看到包括设计模式在内的6种框架，我们只讨论其中比较简单且很常用地的一个框架。这个框架就是：带错误处理的子VI。

    如图9-2中所示，用鼠标双击“带错误处理的子VI”，开发环境会打开这个模版，该模板适用于创建子VI。参见下图。

    这是一个非常常用的框架，它贯彻图形化语言数据流的运行机制，为我们提供了一个创建子VI的模板。如果程序设计中需要创建一个子VI，那么就选择这个框架好了。

    该模板利用公共线程——错误簇，实现子VI的设计重用。

    该框架的结构很简单，case结构与错误簇结合，并且错误簇直接接到case结构的分支选择端。它的工作原理是通过case结构的“分支选择器”来判断输入错误簇中布尔量的状态来决定case结构所执行的状态。尽管错误簇中存在有三种数据类型，但case结构仅对布尔量做出反应，其它类型的信息正常传递。

    它的数据流运行机制是这样的：
  程序开始运行时，首先判断连接到“分支选择器”错误簇中的错误状态码：
   如果“错误状态码”＝0，则执行“无错误case“中的正常程序代码（也就是子vi中所要执行的程序代码）；
  如果“错误状态码”＝1，则通过“错误case“将错误信息直接传递到“错误出”的端口。

    错误快速传递是这个vi的最基本特点，它大大的降低了错误信息传递的延迟时间。这里面有两点还需要注意：一是，错误信息是来自前面的子vi；二是，传递的只是错误信息并没有进行任何的报告和处理。

    框架提供了设计上的重用，对于上面所讨论的这个框架，希望在子vi设计中能得到广泛应用。

    这里我们探讨这样一个问题：数据流（编程）是LabVIEW图形化编程语言的一种设计模式吗？

    可以这样讲，正是这个问题的提出，才导致了本书的出现。

    在此前撰写《LabVIEW图形化系统设计和实践》过程中，曾看到有的资料中将数据流被列为LabVIEW的一种设计模式。这种说法引发了笔者的认真思考，思考的最终结果就是导致了《LabVIEW编程思想》一书的出现。

    在《LabVIEW编程思想》一书中，笔者将数据流编程看作LabVIEW图形化语言的核心编程思想而不是设计模式完全是基于这样的理由：

    其一，使用LabVIEW图形化编程语言进行程序设计必须依据数据流的编程原则。这是应用LabVIEW图形化编程语言的充分且必要的条件，别无其它方式选择。所以，我们将数据流编程被看成是LabVIEW图形化编程语言的核心编程思想。

    其二，虽然设计模式是设计思想的重用，但并不是强制和必须的。而图形化语言数据流的设计思想是强制的和必须采用的。是LabVIEW发明之初就已经十分明确和确定的，并不需要程序员在实践中加以任何验证和总结。

    所以笔者认为：LabVIEW图形化语言的核心编程思想是数据流编程，数据流编程思想不应该列为图形化语言的设计模式。