I've posted a document on my personal website on the topic of LabVOOP Design Patterns.

Here's a bit from the introduction to let you decide whether you want to dive into the whole document. Feedback is welcome. Eventually I'd like to put this up on DevZone, after it has a bit of polish, but it has not been reviewed by any tech writers yet.

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.

Nicely done Stephen - thourough, and I especially appreciate your parallel to the gang of four patterns This document should definately become part of the LabVIEW documentation in the future. Now it's our job to further define the patterns that you've listed, and maybe come up with new ones where appropriate...

I also like (and agree with) the "whole new flavor of über-geek nirvana!"

I would greatly appreciate LabVOOP design patterns. However you Aristos mentioned in another post that LabVOOP that it's currently hard to know which is the best design since the language is so new. So I don't think that a fixed document can do the thing, LabVOOP design patterns will evolve for some time until we the community understand what is the best way to implement different things in this language. So instead of document I'd appreciate a kind of online design pattern library. Each design pattern should include

• name of the pattern
• verbal description of the pattern
• UML of the class hierarchy
• images clarifying the central parts of the code (png not jpg)
• example code as a zip packages
• discussion forum about the pros and cons of each design pattern in slashdot style, everybody can comment and suggest new design patterns but only the moderators can add new design patterns to keep the quality of patterns

The PDF is what you just asked for -- name, verbal description, image, link to example code, editorial comments. it's the best I've been able to pull together thus far. The patterns I've included are reasonably sound concept wise for LV... its the implementations that are questionable. The UML component, for example, will be hard to stabilize for some time, thus I didn't even attempt it in this draft. If you're looking for discussion about each individual pattern, I didn't think it was worth, at this point, starting a separate discussion forum for each one. You can do so if you think it's worth it.

UML is very fast to comprehend where as reading pages of text is slow and still you may miss the point. I think UML would be even more important than the text. Drawing the most important classes and their relation is not a big task. If you use something like MS Visio to draw the UML and include these drawings in a word document, you can update the drawings in a few seconds if you change the class structure of the pattern. I think UML is a must for design patterns.

I finally had time to rewrite the Singleton Pattern for LabVOOP.
http://jabberwocky.outriangle.org/SingletonPattern.zip

Here is the accompanying text:


Singleton Pattern
(adapted from Gang of Four’s Singleton pattern)

Intent
Guarantee that a given class has only a single instance in memory, that no second instance can ever be created, and that all method calls refer to this single instance.

Motivation
When you create a class, sometimes it is advantageous to guarantee that a program always refers to the same global instance of the class. Perhaps the class represents a database. It would be unfortunate if some section of code accidentally instantiated its own database and thus failed to update the global database. Creating a global means all VIs can access the data. But it does not mean that all VIs will access the global. This pattern describes a framework of classes that guarantee that single instance of data.

Implementation
See
http://jabberwocky.outriangle.org/SingletonPattern.zip

(An example of this pattern shipped with LV8.2, but that example is flawed, a problem I did not realize before we released: \examples\lvoop\SingletonPattern\Design Pattern.lvproj )

In this implementation, we seek to guarantee a single instance of Data.lvclass. We achieve this by putting Data.lvclass into an owning library, Singleton.lvlib, and making the class private. Now no VI outside the class can ever drop the class as a control, constant or indicator, so we guarantee that all operations are limited to this library. Callers can use Singleton.lvlib:Checkout.vi to get the current value of the data, modify it using any of the operations defined by Singleton.lvlib and then set the new value with Singleton.lvlib:Checkin.vi. The public functions are the same functions that would normally be on the class itself. They are moved to the library so that the functionality is exposed without allowing the class itself to be dropped. Checkin.vi and Checkout.vi use a single-element queue to guarantee only one copy in memory at a time. While the element is checked out to be modified by some routine, no other operation can proceed, thus guaranteeing serial access to the data.

Editorial Comments
I do not like the implementation that shipped with LV8.2. In the time since LV8.2 released, I have found better ideas. This “post-release discovery” is one reason why more design patterns are not included with the shipping product. LabVOOP is too new, and many of the patterns identified during development may be found faulty when exposed to a wider audience (i.e. real customers). So I'm making this revision available.

The only hole in the above solution that I can find is VI Server. VI Server could get a reference to the Front Panel controls of Singleton’s member VIs and use the Value property to effectively manipulate a different instance of the class than the one in the queue. Would using Subroutine Priority prevent VI Server access? I think so, but that seems like a pretty odd way to fix these VIs. The fix may not be that necessary – I doubt that many people are going to attempt such a hack on the class. Anyone trying it is already aware that they’re working against the design of the class and may break components that depend upon the singleton nature.

Elegant This way I think I can also force the use of class constructors.

I hadn't thought of it that way, but you're right. By embedding an Initializer in the place where we setup the queue. Then there's no way to get one of these values that hasn't been through the initialization function.

After some more chaotic brain activity.... this pattern works. It's however somewhat more complicated to develop than a regular class and some limitations arises from the fact that public class methods need to be outside the class. So I have a suggestion for the future releases of LabVIEW which would make this pattern simpler.

The trick is that if user could define the access scope of the class constant/control, then the user could force the class to be initiated trough the class "constructor" and the singleton pattern would be easy to implement without any external library embedding. This addition would also make it possible for the class user to force constructor calls when needed.

A user could place private controls on front panel, but the VI wouldn't run if the control wasn't connected to an external buffer source (i.e. if the VI wouldn't called as a subVI). The user could also place private constants on block diagram. These constants wouldn't initiate a buffer but would only carry type information. A wire leaving from these constants could only be conntected to new kind of node terminals called "Type specifier" terminal. All sorts of typecast and unflatten functions would have this new terminal instead of the present "required" terminals. User could also define front panel terminals to be of "Type specifier" type, but then these terminals could only be conntected to other "Type specifier" terminals.

Aristos, do you think you could implement this in a future release of LV. After all it seems to me quite powerful addition to the language

Edit: Some more brain work.... your design pattern would also allow users to make pure virtual classes

This post has been edited by jimi: Sep 5 2006, 09:41 AM

Worth thinking about, certainly. At this point I don't see any pitfalls.


My brain is going slow this morning. How does this work?

Oh, and I did find one hole in the entire solution... uninitialized shift registers. An unscrupulous programmer can connect the terminal output of one of the exposed VIs to the inside terminal of the right-hand shift register. Then the left-hand shift register, if left unwired, would be able to produce an uninitialized (in the most terribly litteral sense!) value of the class. To really enforce the pattern, I would need to force shift-registers to be wired if they cannot access the class.

I was wrong, you cannot



I think uninitialized shift registers and all other VI properties with state cause quite a lot of trouble since they don't really fit into a pure dataflow ideology. I'd like to see a possibility to have stateless VIs which could be used to implement real recursion.