LabVIEW object-oriented programming FAQ

This is a stub page for Frequently Asked Questions (FAQ) about LVOOP. Please feel free to add to the list of FAQ and answer any of the questions that have been posted.

You may find many questions already answered on the LVOOP FAQ on NI's website. That FAQ will be updated by NI for new versions of LabVIEW and new OO tools as they become available.

Why is class data private?

In general object-oriented programming terms, attributes (like methods) can have private, protected, or public visibility. In practice individual object-oriented programming languages have differing capabilities when it comes to specifying visibility. In the UML attributes are generally assumed to have private visibility unless otherwise specified. (Operations, on the other hand, are assumed to be public unless otherwise specified.) Generally, OOP style guides say never to give attributes public visibility, and the so-called “Law of Demeter” in its strong form limits attribute visibilities to private. In other words, access to data in a class from outside the class is always through accessor methods (‘set’ or ‘get’) methods. In LVOOP this is the only choice, a decision designed to promote good code designs with minimal coupling. (See further here: [1]). (Note that LabVIEW 8.5 introduces a “Create Accessor” dialog box to simplify the creation of accessor methods. For more information on this dialog box see the LabVIEW 8.5 Upgrade Notes here: [2].)

What are the differences between public, protected, and private class members?

In Object-Oriented Programming terms these generally mean:

A private feature (UML abbreviation -) is accessible only from the defining class. A public feature (+) is accessible from outside the class. A protected feature (#) is (in C++, for example) accessible from the defining class and any of its child classes. The UML also has an abbreviation for package (~) visibility. The exact meaning of the different visibilities varies among different programming languages.