3 Simple Object-Oriented Design Patterns in LabVIEW

Publish Date: Jan 27, 2012 | 14 Ratings | 3.64 out of 5 | Print | 1 Customer Review | Submit your review

Table of Contents

  1. Factory Pattern
  2. Command Pattern
  3. Decorator Pattern

It’s easy to recognize code that uses standard design patterns versus code that doesn’t—it’s the difference between being able to understand how the application works and having no idea what’s going on without spending a significant amount of time studying the code. This is especially important when working with a team of developers or when developing an application that needs to be maintained over a long period of time. In either scenario, it’s highly likely that someone besides you will have to modify or update the code. This person may not be an expert in exactly what your application does, but if it uses a familiar design pattern, he or she will at least be able to recognize familiar constructs and quickly start contributing.

Proficient NI LabVIEW software programmers should be aware of a handful of G-specific design patterns, including state machines, functional globals, and producer-consumer loops. LabVIEW programmers should also look to apply concepts from the computer science realm to address problems that are universal to all languages. Some of the best-known patterns were first published by a group of authors known as the “gang of four” in a book titled Design Patterns: Elements of Reusable Object-Oriented Software. Since then, the list of object-oriented design patterns has continued to expand to address the growing number of complex software challenges.

One of the first steps when designing software should be to identify where and how you can use standard patterns in your application. This process requires isolating and defining what needs to be achieved to meet specific design requirements, which is a level deeper than the overall architecture of the application. There are numerous examples of patterns and the problems they address, but as a starting point, consider the following three patterns and their implementation in LabVIEW.

1. Factory Pattern

The factory pattern has been referred to as the most commonly used pattern in modern languages. A factory creates objects without exposing the instantiation logic to the client and refers to the newly created object through a common interface. It’s generally used in applications that have a plug-in component, or some functionality that needs to be loaded dynamically at run time. This requires the definition of a generic parent object, which encapsulates functionality that can then be reused and even extended by children.

Figure 1. With this simple LabVIEW code snippet, the application can load children of “Generic Plugin.lvclass” at run time without having to be aware of the children or their specific functionality beforehand.

Back to Top

2. Command Pattern

The command pattern is especially relevant to LabVIEW programmers, as it can help address some of the challenges associated with sending a command or message between processes. This typically requires coupling the command with any data required by that command to execute, which is often achieved using a cluster containing the command as an enumerated constant and a variant for an arbitrary data type. The command pattern instead creates a new instance of a child class to represent the specific command, which defines the information to be associated with the command within the private data. 

Figure 2. The command pattern uses child classes to represent commands or messages that need to be sent to a consumer loop. Data associated with the command is stored within the object, and the execute method is overridden by each specific class to implement the functionality required to handle the specific message.

Back to Top

3. Decorator Pattern

Developers often design applications knowing that more functionality will need to be added at a later date, but this is best done without the risk associated with modifying tested, pre-existing code. The decorator pattern can help in such a scenario by making it possible to add responsibilities and information dynamically to an object.

Figure 3. The original object, which is a dark roast coffee, is decorated with additional properties by children of a separate hierarchy for condiments. The set of condiments can dynamically be expanded without modifying peers. Invoking the methods to get the cost and the description recursively iterates through all the decorations to aggregate the total values.

These three patterns are simple examples that illustrate how you can use object-oriented design patterns to solve common problems.

- Elijah Kerry

Elijah Kerry is a senior product manager for LabVIEW at National Instruments. He holds a bachelor’s degree in computer engineering from the University of Missouri at Columbia and is a Certified LabVIEW Architect.

Download examples and see more ways you can apply object-oriented design patterns to LabVIEW.

Back to Top

Customer Reviews
1 Review | Submit your review

  - Jan 27, 2012

In the conclusion is written: "These four patterns are simple examples". Really the text is about three patterns, isn't it?

Bookmark & Share


Rate this document

Answered Your Question?
Yes No