During this almost 20 years that I have been creating LabVIEW software, I have certainly followed (and sometimes participated) in the good old debate as whether or not LabVIEW is as good of a programming language as its text based counterparts. The advocates of text based languages bashed LabVIEW and assigned it to the category of a subpar programming environment. One of their old arguments was that it is very difficult to create truly modular, reusable, expandable software in LabVIEW, especially in the case of a large code base, as LabVIEW was not an inherent object oriented programming language.
Since then, the LVOOP (LabVIEW Object Oriented Programming) was launched a few years back in the hopes of turning these infidels into believers of the G paradigm. It has, in fact, progressed into something that is actually fairly powerful if used properly. This link shows an introduction on how to do OO in LabVIEW for the ones of you who are curious about it. National Instruments also created a fully fledged framework, called the actor framework, which expands these original LVOOP concepts into a set of classes one can use to build modular, scalable and parallel processing LabVIEW applications at the same time that it mitigates the risk of deadlocks and race conditions.
Before LVOOP came to life, and actually still do date, my counter argument to the statement one can’t write as professional of a code base in LabVIEW as text based languages always was that object orientation is a philosophy, a way of thinking and designing software, not only a simple syntax implementation on a programming language. As such, even though LabVIEW was not an inherent OO language, it could indeed be used to create large code base that was just as modular, expandable and reusable as its text based friends, if the LabVIEW software was designed with the OO paradigm in mind.
The ones of you who have not endeavored into the wonders of LVOOP yet, and trust me, the learning curve is not trivial, fear not. One can still create OO-like software with the good old LabVIEW, as long as the design is OO-minded.
Without taking a deep dive into OO, the whole point of it is to encapsulate functionality into self sustained blocks of code. What this means in the high level is that a block of code assigned to implement specific functionality will contain in itself all the information and sub-functions needed for such implementation. Moreover, this block of code would provide ways for other blocks of code to interact with it, without becoming heavily coupled with them. What this means is that properties of this block of code can’t be freely modified by other blocks of code, only by its internal sub-modules. Moreover, some its sub-modules would be made available to be called by external entities and others wouldn’t. The properties and sub-modules that can be accessed by external entities are called public and the ones that can’t are called private.
With these concepts in mind, let’s trace a parallel with regular LabVIEW. LabVIEW does have a construct that has been around for decades named lvlib. Lvlib is a LabVIEW library; which is basically a self sustained block of code that executes specific functionality. Based on the OO definitions above, one can immediately see how an lvlib could be a great candidate to become one of the self sustained blocks of codes I mentioned. In the OO world, such block of code is called a class. I am going to avoid that nomenclature as a class does have other features that can’t be accomplished with basic LabVIEW such as inheritance and method overloading. However, these limitations shouldn’t turn you off from this way of creating LabVIEW software that is OO-like.
In the LabVIEW project environment, one can set the access scope of folders inside lvlibs as private or public. If a folder is set as private, all of its content files (subVIs and Typedefs) can only be accessed by subVIs that belong to the lvlib. The ones set as public will be open access to code outside the lvlib. With this little nugget of information, one can create an API folder for public access. This folder would contain all subVIs that would be accessible to the world as well as have a typedef containing what is meant to be the public parameters for this block of code. The other folders inside the lvlib are made private scope; which will host the private subVIs and typedefs that will implement the specific functionality assigned to the lvlib.
As it was said, this is not a full blown OO implementation using LabVIEW, but if you play your cards right in the design of the application, you can have a fully reusable, modular, expandable and maintainable code base in regular LabVIEW by using this technique.