LabVIEW Object-Oriented Programming Design Patterns
An excerpt from the linked .pdf document: When talking about computer programming, a design pattern is a
standard correct way to organize your code. When trying to achieve some
particular result, you look to the standard design patterns first to
see if a solution already exists. This sounds a lot like an algorithm.
An algorithm is a specific sequence of steps to take to calculate some
result from a set of data. Generally algorithms can be written once in
any given programming language and then reused over and over again.
Design patterns are rewritten over and over again. For example, in
house cleaning, consider this algorithm for vacuuming a carpet: “Start
in one corner, walk horizontally across the floor, then move to the
side and continue making adjacent parallel stripes until the whole
floor is vacuumed.” Compare this with the design pattern for cleaning a
room: “Start cleaning at the ceiling and generally work your way down
so that dirt and dust from above settle on the still unclean areas
below.” Design patterns are less specific than algorithms. You use the
patterns as a starting point when writing the specific algorithm.
LabVIEW began shipping with template VIs for common design patterns in LabVIEW 7.0. You can find them in the File>>New...
dialog. The design patterns discussed in this document are new patterns
that emerge with LV8.2 and the introduction of Object-Oriented
Programming for LabVIEW.
Included herein is new ways of dynamic
loading LabVIEW functionality, new ways of writing functional globals
(LV2-style globals), and new ways of handling cluster data. I've
included demo VIs for most of the patterns.
The document below has been available on LAVA
for since August 2006, in an effort to get feedback on a research
concept without giving it the official "NI Stamp Of Approval" that
tends to be attributed to R&D posts to DevZone. After a bit of
revision, this document is ready for a wider audience. But it is still
a work in progress, and will likely remain that way for a couple
versions of LabVIEW. A path in the grass is not worn by one set of feet
treading over it; patterns take time to emerge. http://jabberwocky.outriangle.org/LabVOOP_Design_Patterns.pdf
Feedback is welcome. If
you want to comment on the document as a whole, reply here. If you want
to discuss a particular pattern, it would probably be good to start a
new topic specific to that pattern so that conversations don't get
I agree that design patterns are important part of Object Oriented Programming as they provide an elegant way of getting around a programming problem that often occurs. LabVOOP is a new object-flow programming language with many distictions to traditional text-baset OOP programming languages. Especially it's a by-value OOP programming language that doesn't allow object references. Furthermore LabVOOP doesn't allow recursively calling dynamic class methods. In addition LabVOOP doesn't have built-in mechanisms for user-defined object initialization, object copying and object cleanup. These restrictions put LabVOOP into very different position compared to traditional OOP languages. Indeed many tasks that are trivial in traditional programming languages are quite hard to implement in LabVOOP.
Due to the above mentioned LabVOOP restrictions I think the LabVIEW community would need special LabVOOP specific design patterns more than these general OOP design patterns. These patterns would be trivial to implement in OOP languages but are far from trivial in LabVOOP. There should be design pattern for at least the following things
initializing an object that needs initialization, and whose ancestor objects also need initialization
forcing initialization so that object always represents something meaningful
creating copies of objects that refer to files or other real world objects
cleaning up hierarchical structures such as object hierarchy representing file system with references to open files (this is very difficult in general because recursive calls are not allowed)
modifying hierarchical structures such as object hierarchy representing file system, how to modify an object somewhere deep in the hierarchy such as renaming a file C:\mydir\myfile to C:\mydir\mynew_file
representing graphs using object hierarchies (naturally by-value hierarchies form trees, not graphs)
See LAVA forum (http://www.lavag.org) GOOP subforum for more detailed examples of the above mentioned programming problems. By the time I was writing this, LAVA forum web site was down, my appologies that I cannot directly link to relevant threads.