Design patterns for data storage

[Jon Sjöstedt]

Hello all!

First post.

I wrote a long nice message and then IE crached.

Im looking for design patterns for encapsulation and protection of data. Very much like an object with private data (but not a singleton). I would like to accomplish this by not using LVOOP. Data/object should be referenced by a refnum (I imagine). Guess there is a default solution to this that I dont know of.

All ideas welcome!

[Francois Normandin]

QUOTE (Jon Sjöstedt @ Jul 31 2008, 03:38 AM)

Hello all!

First post.

I wrote a long nice message and then IE crached.

Im looking for design patterns for encapsulation and protection of data. Very much like an object with private data (but not a singleton). I would like to accomplish this by not using LVOOP. Data/object should be referenced by a refnum (I imagine). Guess there is a default solution to this that I dont know of.

All ideas welcome!

Some people on this forum are far better than myself to give advice on this topic, but you might want to start by looking at http://wiki.lavag.org/Functional_global_variable' rel='nofollow' target="_blank">Functional Global Variables. Not the perfect solution for data protection... but it's a start to build on.

May I ask why you don't want to use LVOOP or GOOP? Are you developing for an RT system?

[eaolson]

There's always dqGOOP. Works via refnums, as you wanted. It works in pre-LV-8 versions, too.

[Yair]

As mentioned, dqGOOP works very well and there are other by-ref GOOP toolkits around (e.g. Endevo GOOP, Sciware GOOP), but you can also have by-ref wrappers for LVOOP, and there's even a shipping examples. Additionally, if you search the forums, you should find a link Aristos Queue posted to a list of design patterns implentations in LVOOP.

[Jon Sjöstedt]

Sorry for my late reply. Vacation...

normandinf: There is some "political" resistance within my organization against OOP in general, caused by improper use in previous projects. I'm also impressed by those *OOP-packages that allowes access to data using ref's and would like to know if there is an easily reuseable method behind it.

By experience I guess that the newly introduced (lv8.2) OOP-constructs are not that reliable (I am unfortenately stuck with lv8.2) until a few versions later.

[Yair]

QUOTE (Jon Sjöstedt @ Aug 8 2008, 04:30 PM)

normandinf: There is some "political" resistance within my organization against OOP in general, caused by improper use in previous projects.

There are never any guarantees in software, but you should try to diagnose the situation to see what went wrong and what can be done about it (e.g. maybe OOP wasn't appropriate, maybe it was implemented by people who didn't understand the concepts, maybe it wasn't designed well enough)

QUOTE

I'm also impressed by those *OOP-packages that allowes access to data using ref's and would like to know if there is an easily reuseable method behind it.

These tools usually have a template and a wizard which copies that template, so that much is reusable, but you usually don't need to know about it, because the wizard does all the work. If you're asking about whether you can have inheritance or write code for one class and reuse it, that highly depends on which implementation you use and how you write your code. Some of these are free (like dqGOOP), so you can just download it and see.

QUOTE

By experience I guess that the newly introduced (lv8.2) OOP-constructs are not that reliable (I am unfortenately stuck with lv8.2) until a few versions later.

I don't know any specific details, but there were certainly issues with LVOOP in 8.2 which were resolved in later versions. You can see details by looking through this board and looking at NI's known issues documents.

[Jon Sjöstedt]

Guess this was unclear

QUOTE

I'm also impressed by those *OOP-packages that allowes access to data using ref's and would like to know if there is an easily reuseable method behind it.

Clarification attempt: I am not looking for OOP design elements in general. I am specifically interested in a way to access data in pointer-style (=refnum?). Dataprotection is desireable if possible. I have noted the very elegant LV2-style singleton design (which uses no magic *OOP-package or LVOOP) and need to complete it with a non-singleton datastorage. Hope this was more clarifying than confusing...

I will look into dqGOOP and see if that gets me where i want. Thanks for all help so far!

[LAVA 1.0 Content]

QUOTE (Jon Sjöstedt @ Aug 11 2008, 04:01 AM)

Clarification attempt: I am not looking for OOP design elements in general. I am specifically interested in a way to access data in pointer-style (=refnum?). Dataprotection is desireable if possible. I have noted the very elegant LV2-style singleton design (which uses no magic *OOP-package or LVOOP) and need to complete it with a non-singleton datastorage. Hope this was more clarifying than confusing...

Shameless Plug: You may also want to look at the Current Value Table implementation, available on ni.com.

Current Value Table (CVT) Component

A Current Value Table for LabVIEW

It uses the FGV design to implement data storage for any number of tags or values in your application. The data or values are accessed by name or by index (refnum), your choice. In the current design you must initialize the CVT at the beginning of your application with the list of variables you will be using. This list is passed as an array of clusters to the Init VI and can be created dynamically, defined statically (constant), or read from a file. The current implementation includes support for scalar Boolean, Doubles, I32, Strings, and Enums. It can be easily extended to other data types. Arrays are a bit more tricky and are not included in the published code. I do have a trial implementation for arrays that I can send you or post on request.

Please provide any feedback or suggestions for the CVT in the provided discussion forum. General questions I can answer here.

[Yair]

QUOTE (Jon Sjöstedt @ Aug 11 2008, 12:01 PM)

I am specifically interested in a way to access data in pointer-style (=refnum?). Dataprotection is desireable if possible.

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=305242#M305242' target="_blank">This example is implemented using dqGOOP. You also have VIs there which you can download to see how it works.

P.S. Christian, nice work on the CVT and the components in general. I think creating tools like this is very useful. Any reason why these components don't ship as standard in vi.lib?

[LAVA 1.0 Content]

QUOTE (Yair @ Aug 11 2008, 12:58 PM)

P.S. Christian, nice work on the CVT and the components in general. I think creating tools like this is very useful. Any reason why these components don't ship as standard in vi.lib?

Thank you. These are not included in the standard product for several reason. The quick reasons are documentation, testing, maintenance, support, forward compatibility, etc. It takes a lot more time and effort to add a feature or set of VIs into LabVIEW and maintain them long term than my group can provide. We are not part of R&D and don't pretend to develop products. Our goal is to share with the wider LabVIEW community things we learn and code we develop while working with customers and integrators on individual applications. In short we have the same motivation as the LAVA community; to improve the experience of LabVIEW users by sharing what we know and do.

In addition we like to use what we publish on DevZone as a trial run and sounding board for possible new features and VIs to be added to LabVIEW and other products in the future. By not including the VIs in LabVIEW right away we're not committing to a particular functionality or API until we feel it is ready for the product. Some of the code we have developed has made it into examples shipped with LabVIEW. Specifically the LabVIEW Touchpanel module 8.6 includes a reference design based on code we published last year. However, in general what we do and the feedbapck we provide to R&D makes its way into the product in other more hidden ways, e.g. by improving current features or adding new features that may look different from the original solution we provide. For example, the cRIO I/O Engine (CIE) we published last year has just been surplanted by the Scan Engine and RIO Scan Interface released in version 8.6. This effectively negates the need for one of the reference designs we published last year, which is exactly what my group likes to see.

[jzoller]

Check out DFGray's very nice reference object benchmarks.

Joe Z.

[Jon Sjöstedt]

The dqGOOP installer did not work on my windows machine (note: I run lv remote on a linux machine). Can the dqGOOP framework be fetched in a more general format? dataact.com didn't answer my mail...

Edit: Got my hands on dqGOOP-core