Finally, here we are!
After months of stacked thoughts and several (mental) parliamentary questions, here is post 0 inaugurating this blog. The first of a (I hope!) long series to mainly delve into the subject of object-oriented programming declined to the LabVIEW* world.
Well, now let’s get started.
Unlike other natively object-oriented languages such as Java and C#, Labview is not. The support for the OOP world in LabVIEW was introduced in 2006, with LabVIEW 8.2. Although almost 20 years have passed since 2006, during my work-experience I have realized that object-oriented programming is, at least in Italy, still poorly practiced.
In my opinion, there are mainly two reasons for this. First, the mindset of us LabVIEW developers. As I mentioned a few lines ago, classes in LabVIEW have been available since 2006, and many developers who started using this programming language earlier have become accustomed to programming according to the “classical” method. It goes without saying that often new generations of developers, receiving training from the ante-OOP developers, get used to the classical method precluding themselves from learning about alternative and undoubtedly more powerful ways of implementing their applications. Another reason why OOP is impractical is because the new LabVIEW developer often does not have a computer science background and learns to program in a non-computer context. In fact, LabVIEW is often used in laboratories, research centers, and quality control departments because it is preferred over other languages given its natural ease, speed, and versatility in bringing testing (data acquisition, processing, and visualization) applications to life. In these contexts, object-oriented programming runs the great risk of being sidelined.
Detractors of object-oriented programming could easily dispute that software can be just as well developed without the OOP approach. This is true but failure to use this paradigm is limiting. In the following image I have summarized the advantages provided by the OOP approach.
Improved maintainability of the existing code
Reusability of code
Improved modularity of applications
Shared software development
Improved project management
Natural design
As illustrated above, the OOP approach enables modular code by ensuring shared development on the same software project. In addition, the code is easier to maintain, cleaner and neater, and at the same time project management is easier.
Finally, the OOP approach provides natural support for software modeling of real-world objects or of the abstract model to be reproduced which greatly simplifies design. For example, assuming you need to create software for library loan management, you will likely need to define the Book, Loan, and Person (or User) classes.
Well, that’s all for now. See you again in the next post.
In the meantime, I leave below a couple of in-depth links on the topic:
- LabVIEW Object-Oriented Programming: The Decisions Behind the Design
- LabVIEW Object-Oriented Programming FAQ
* When mentioning LabVIEW, I refer to the G language for which LabVIEW is the only development environment.
