Today's nugget has to do with the organization of data in a LabVIEW Class. I have really only embraced LabVIEW Class programming within the past year, which probably makes me a late adopter compared to other LabVIEW architects. But when I first started using classes, I took what I assume is a pretty standard approach to creating data member access VIs...every time I added a new data item to my private data control, I created read/write accessor VIs for that item. One thing I noticed fairly quickly was that this really bloated the codebase of my LabVIEW Class-based apps. It also became a maintenance headache when I needed to add/remove/modify items in my private data control, because I had to go add/remove/modify the data member access VIs as well. So in my current LabVIEW Class-based project, I have taken a different approach: In this example, my private data control now only contains a single element...and that is a typedef cluster (Harness Data.ctl in the screenshot above) that itself contains all the data items for my class. With this approach, I now have a single read and a single write VI that gains me access to all the data in my class. If I need to add/remove/modify items, I only do it in the typedef cluster, and the read/write VIs don't need to change. The only disadvantage I've encountered to this approach is that each read/write in my code also requires an Unbundle By Name/Bundle By Name, respectively. But I find this requirement to be much less of a burden than having to maintain a library of accessor VIs, especially since the adding/removing/renaming of VIs on disk is an extra headache when your project is in SCC, as mine always are. I realize that this approach "publicizes" all the data in my class. For my apps, whose interfaces have all been internal to this point, this is not a concern. But I imagine for a LabVIEW Class-based app where there is a public interface, you would be going through extra work anyway to create public accessors for data, so as long as the Read/Write VIs that access the entire data cluster are private, it shouldn't be a concern. One final note: Since I am relatively new to LabVIEW Class development, I'm guessing there are theoretical reasons why this approach isn't the best. But so far, I've found data member access to be a much easier endeavor with my current organization than with my previous. So if you have any ideas about how my approach may break down in the future, speak up!

LabVIEW

Darren's Weekly Nugget 07/19/2010

Consider the hot dog example for the implementation vs interface question. You, as a user of class HotDog, want only to extract the Taste and SaltyGoodness from the HotDog class. You probably don't want to have access to Ingredients, NutritionalContent, and ManufacturingProcessDetails. Sure, it might be interesting, but did you really need that information?

Cheers,

Matt Pollock
National Instruments