Refactoring the ReferenceObject example in LV 8.2

Posted on Saturday 19 August 2006

objectWhen I first got my hands on LabVIEW 8.2, I was really curious to see some of the shipping examples that show how to use the native object-oriented features in 8.2. I was extremely happy to see an example on objects by reference (ReferenceObject.lvproj).

Now, I’m not going to get into a debate on which is better, by value or by reference. These two features are not mutually exclusive. In fact, references are values, so it is very easy to develop by reference objects using the OOP in 8.2 – and eventually NI will implement a native by reference object management scheme (I hope). There I said it, let’s move on.

So, back to the story… I took a look at the ReferenceObject.lvproj example, and was really happy to see a pattern with a locking mechanism for shared data. While the support VIs (that implemented the data access and locking) were named different, they were basically the familiar GetData (read), GetDataToModify (read+lock), and SetModifiedData (write+unlock). I thought, “hey, I know what do with those!”

But, I had some initial thoughts…

1) The example uses a single element queue as the object reference. The object instance data is the single element that’s in the queue, and the queue reference points to the object instance. There will be a unique queue for each object instance. OK, this is basically just dqGOOP. I’ve used that pattern before, so I’m comfortable with that.

2) CheckOut (read+lock) and CheckIn (write+unlock) are public VIs of the ReferenceClass. IMO, they should definitely be private. Only the class member VIs should be accessing/locking/unlocking the object data directly.

3) I prefer the data access VIs to be named GetData, GetDataToModify, and SetModifiedData (instead of CheckOut and CheckIn) and I like them have the familiar lock and unlock icons, just like old-fashioned GOOP.

get unlock lock

4) There are two classes used to implement the by reference object. The purpose of SimpleObject is to insulate ReferenceClass’s Queue Refnum (reference object data type) from type changes of the data cluster. That’s pretty cool.

5) There are accessor methods in SimpleClass. It would be a whole lot easier to have just two methods, “object to data” and “data to object”, in SimpleClass and then put all the accessor methods in ReferenceClass. Again, I think that the only purpose of the SimpleClass should be to insulate ReferenceClass’s Queue Refnum from type changes to the data.

6) The SimpleClass data should be one cluster (a typedef, of course), so that ObjectToData and DataToObject can get all the data in a single element, instead of unbundling and bundling multiple elements.

Reference ClassI decided that it would be a good idea to refactor the ReferenceObject example, to see if I could improve upone the pattern’s design. I wanted to improve upon the original example and optimize it for two main considerations:

  • Developer effort to maintain the class
  • Run-time Performance

While there was no one perfect solution, I did come up with three new examples. Each of these balancing the considerations in different ways.

ReferenceObject_JK01 (ReferenceObject_JK01.zip 133KB)

This example uses a value object (SimpleClass) as the queue element of the reference object (ReferenceClass).

Pros:

  • Cluster data type can be changed without changing the type of the Queue Refnum (which requires the user to manually redefine the queue refnum type).
  • Fast – Since the by reference object’s instance data is never flattened/unflattened, there is no performance penalty.

Cons:

  • There are two classes required for each class. This requires a lot of extra work for developers, to maintain all these extra classes and the linkages between support VIs.

ReferenceObject_JK02 (ReferenceObject_JK02.zip 119KB)

This example uses a flattened string as the queue element. The object data cluster is flattened and unflatted when enqueuing and dequeuing into the ReferenceClass queue.

Pros:

  • Cluster data type can be changed without changing the type of the queue refnum, since the queue data is the flattened string of the cluster.
  • There’s only one class

Cons:

  • Slower – Since the by reference object’s instance data is flattened/unflattened, there is a performance penalty.

ReferenceObject_JK03-1 (ReferenceObject_JK03-1 115KB)

This example uses a cluster as the ReferenceClass queue element.

Pros:

  • Fast – since the by reference object’s instance data is never flattened/unflattened, there is no performance penalty.
  • There’s only one class

Cons:

  • ???

Final Thoughts

Another implementation of the ReferenceObject would be to use a variant (rather than a flattened string, as in the second example). NI has done some optimization of the variant (in LabVIEW 8.0), which might make this a feasible choice.

One new LabVIEW feature (which is utilized by the 3rd example) is that a queue refnum created by selecting Create Indicator from an Obtain Queue will be dynamically linked to the type definition wired to the Obtain Queue’s element type input. This means that you will not have to update the queue reference when you change the data cluster type definition. This ia really cool! I’m not sure yet when this feature first appeared, but it’s absolutely great! Thank you, Philippe Guerit, for telling me about it (I hadn’t realized this when I first wrote this article). So, with the a dynamic linkage between the data cluster and the queue refnum, the third example, ReferenceObject_JK03-1, is the hands-down winner for both efficiency and ease of development and maintenance!

If you would like to discuss these examples, design patterns, OOP, or anything LabVIEW related, I encourage you to post to the LAVA discussion forums. I have created a topic just for this thread.


  1.  
    Jaegen
    August 24, 2006 | 2:27 pm
     

    Jim,

    First of all, thank you for GOOP – I’ve been using it for years now with great success.

    I have yet to fully wrap my head around the whole “By-Value” vs. “By-Reference” thing (I’m only a pretend computer scientist), but my heart did sink a little when I discovered LVOOP was “By-Value”. That being said, your third example looks promising.

    Like I said, I haven’t fully worked out the details, but I was wondering if you knew how an implementation like this (#3) affects inheritance. Can your “ReferenceClass” properly act as a parent now that it’s really a queue?

    Thanks,

    Jaegen Milley

  2.  
    Jaegen
    August 24, 2006 | 2:29 pm
     

    Sorry – just saw the note re LAVA … I’ll go there.

  3.  
    Jaegen
    August 24, 2006 | 4:19 pm
     

    … and of course I meant “OpenGOOP” …

Sorry, the comment form is closed at this time.

Bad Behavior has blocked 772 access attempts in the last 7 days.