Object-Oriented Design Patterns
- Factory Pattern
- Command Pattern
- Decorator 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.
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.
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 (see Queued Message Handler and Actor Framework). 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.
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.
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.
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.
"Applying Common Object-Oriented (OO) Design Patterns to LabVIEW" - by Elijah Kerry, National Instruments
The seminal text on design patterns appeared in 1995: Design Patterns by Gamma, Helm, Johnson and Vlissides. This text is colloquially known as “the Gang of Four book.” This text focused on object-oriented design patterns, specifically those that could be implemented using C++. Many of those patterns are predicated on a by-reference model for objects. As such they apply very well to classes made with the GOOP Toolkit (or any of the several other GOOP implementations for LabVIEW). LabVIEW classes, added in LV8.2, use by-value syntax in order to be dataflow safe. This means that the known patterns of object-oriented programming must be adapted, and new patterns must be identified. This document describes the LabVOOP-specific patterns I have identified thus far. -Stephen Loftus-Mercer
- "3 Simple Object-Oriented Design Patterns in LabVIEW" by Elijah Kerry, National Instruments (http://www.ni.com/newsletter/51506/en/)