Design pattern

A design pattern, also know as a software design pattern, is a reusable solution to a software engineering problem. Design patterns give the developer a starting point and can help improve efficiency, readability, scalability, and maintainability. Using a design pattern can help you easily expand your application and reuse your own development efforts when you want to add new features. Once you create a good architecture for your company, you can create templates that you and others can reuse for future projects.

Described below some useful design patterns that a developer can use in their application architecture. By no means is this a comprehensive list, and no one architecture should be considered as the "best", however it may be helpful to start with one of these design patterns, or variations on them. A good architecture is one that fits best for the application and can be a combination of the design patterns below.

Basic Design Patterns

State Machine

See more on the State Machine Design Pattern.

Event Handler

See more on the Event Handler Design Pattern.

Master/Slave

See more on the Master/Slave Design Pattern.

Producer/Consumer

See more on the Producer/Consumer Design Pattern.

Intermediate Design Patterns

Queued Message Handler (QMH)

See more on the Queued Message Handler (QMH) Design Pattern.

Queued State Machine (QSM)

See more on the Queued State Machine (QSH) Design Pattern.

Action Engine (AE)

See more on the Action Engine (AE) Design Pattern a.k.a. Functional global variable.

Advanced Design Patterns

Object-Oriented Design Patterns

LabVIEW Object-Oriented Programming (LVOOP) uses concepts from other object-oriented programming languages which include class structure, encapsulation, and inheritance. You can use these concepts to create code that is easier to maintain and modify without affecting other sections of code within the application. There are many common Object-Oriented design patterns that can be applied to LVOOP.  See more on Object-Oriented Design Patterns.

Actor Oriented Design

Transition from thinking in dataflow to thinking in message flow. In larger applications with parallel modules in multiple threads, dataflow is insufficient to describe the interaction.  Instead, think of the flow of the messages (methods plus data) exchanged between those modules.  Dataflow makes sense for single processes with shorter lifetimes inside self-contained components.  In large complex applications, the messaging may be such that a dedicated message broker would be needed.  Dataflow will still govern the self-contained code pieces inside the components. See more on the Actor Oriented Design Patterns.

Articles

• LabVIEW Design Patterns Presentation by National Instruments
• State Machine - LabVIEW Design Patterns by LabVIEW Advantage
• State Machine Events SME - LabVIEW Design Patterns by LabVIEW Advantage
• Producer Consumer (Events) - LabVIEW Design Patterns by LabVIEW Advantage
• Queued State Machine QSM - LabVIEW Design Patterns by LabVIEW Advantage
• LabVIEW Design Patterns Badge by National Instruments
• "Design Pattern Case Study: A Simple Counter" - by Quentin "Q" Alldredge, Q Software Innovations, LLC
• "Actor Framework is not as hard as you think and here is why…" - by Quentin "Q" Alldredge, Q Software Innovations, LLC