A Call for Better LabVIEW Design Patterns

[User002]

Part 2 of the code.

BR

Roger

[tst]

ElijahK wrote:

examples that I've seen or heard of include: ...configuration data storage.

I wonder if this is the kind of thing that would be best solved with a template or whether it could benefit more from an addition of a new environment feature. This is the sort of problem which is very common and has some conflicting requirements, not all of which can be easily satisfied with the current tools.

[Nate_Moehring]

I wanted to make sure I thoroughly understood the document AQ referenced before I replied to his post.  I had read it about 2 years ago, but I think I only understood about 75% of it at the time.  So I signed myself up to present the design patterns described by this document in the Phoenix Area Advanced LabVIEW User Group meeting come up this week, and as a result, I now fully understand the contents of this document and can say with confidence that this only partially addresses my original request to have more system level design patterns.

The OO design patterns are very important, but I'd like to see more system level design patterns.  Many applications have similar challenges/requirements such as:

1. Inter-process communication (AMC is great)
2. Managing user configuration settings
3. Implementing User Access Control settings
4. User customizable GUIs

In addition to design patterns for common application module requirements, I'd also like to see more architectural patterns, such as MVC, industry standard architectures for systems of processes/modules that operate in conjunction to achieve a better overall software architecture.  In general the examples that currently that ship with LabVIEW are limited in scope, a single top level VI and some subVIs.  I'd like to see some reference designs that address highly parallel, complex applications that have a heavy emphasis as both data gathering/processing systems, as well as full featured applications with customizable user interfaces and programmatic interfaces for automation and extensibilty.

I'm sorry that I cannot be more specific at this time, but based on other people's replies to this thread, I think the desire is shared by many.  I'd like to spend less time re-inventing the wheel (and wondering if I'm doing it right) when it comes to application frameworks/architectures by having available to me more templates and examples of typical application needs.

Thanks,

Nate

[LabBEAN]

Hi Nate,

If you put together resources (e.g. a slide deck) for the LVUG that expound on / help clarify the "Moving Common OO Design Patterns From Other Languages Into LabVIEW" document, would you mind attaching them?  I (we) enjoy learning new tools / architectures.

Thanks,
Jason

[Ben]

Sorry about the long delay before replying.

THank you Roger for posting those examples!

I am only as far as "ExecutionBase_Create in the first example I looke at but I already had the light-buld flip on. The use of the generic LV Class to define the data used in the queues is very nice. THat was one of the issues I had yet to figure out.

Nice!

Ben

[Nate_Moehring]

I'll be happy to post it after I give the presentation and incorporate any updates that I think should be made based on viewer comments, questions, and internal remarks.

[User002]

The idea with the ExecutionBase is being able to avoid having to ask the eternal question of "Ref or Value". Inherit it to your class and implement "update.vi" and voila, you have both.

It took some trial & error to get it just right. This would have been fantastic to get natively in LV.

/Roger

[User002]

Why should we discourage reinvention and rework of existing patterns? For example, as we have seen, there are many different ways of doing reference based LV oop, good and bad. Let the coders decide what is a good realization of a pattern, and what is not?

In LV there is a gap between the fairly "low level" operations, such as handling arrays, strings, and the other extreme with magic express stuff. The one thing missing is the middle ground with flexible primitives that can be used for any pattern without being overly restrictive. Inherit or use the middle ground and create your own patterns or reimplement existing patterns. To do this, I miss is standard class library such as the one Java offers. E.g. java.io, java.sql, java.xml, etc.

/Roger

[PaulLotz]

Hi, Nate!

I read your post with considerable interest.

We have designed and implemented OO-based solutions for the first two items on your list.  In particular, I think our solution to inter-process communication is far simpler to implement and reuse and many times more flexible than the AMC library approach.  We have also implemented a reusable XML-based configuration interface that is easy to extend and quite clean.  I will actually be at the meeting in Phoenix tomorrow (I'm very eager to hear what you have to say) so maybe we can talk then.

By the way, there is a help file (no libraries) on MVC in the help (http://zone.ni.com/reference/en-XX/help/371618E-01/lvdscconcepts/mvc_design/), but I do not think it accurately describes the M (model) of MVC.  We use MVC here on, well, everything, and I would be happy to discuss that as well.

Paul

[David S.]

Hi Paul -

Any chance of sharing your OOP implementations of AMC and GXML/SimpleXML?