LabVOOP Design Patterns

[AristosQueue (NI)]

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 confused.

[Tomi_Maila]

Hi,

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.

[AristosQueue (NI) · Accepted solution]

THE LINK IN THE ORIGINAL POST IS NOW OBSOLETE. You can now find the design patterns document here:

Applying Text-Based Design Patterns Using LabVIEW Object-Orientation

http://decibel.ni.com/content/docs/DOC-2875

Message Edited by Aristos Queue on 12-19-2008 12:07 PM

[kikiduu]

Since I was not able to access the above link, I am just posting it again.

http://decibel.ni.com/content/docs/DOC-2875