From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW Development Best Practices Blog
- AristosQueue (NI) on: This Blog Has Moved...
- AristosQueue (NI) on: Using Variant Attributes for High-Performance Lookup Tables in LabVIEW
-
AELmx
on:
See you at NIWeek!
-
ramktamu
on:
Video on Measurement Abstraction Layers, MVC and the Actor Framework
-
TroyK
on:
data export to a single excell sheet
-
amandion
on:
When Should the 'To More Specific' or 'Preserve Tun-Time Class' Primitives be Used with OOP in LabVIEW?
-
vishots.com
on:
Best Practices for Dynamic VI Loading (VI Lifetime Management Video)
-
sth
on:
Recorded Virtual User Group on Team-Based Development and Source Code Control
-
PaulLotz
on:
Using Events for Communication Between Asynchronous LabVIEW Loops
- AristosQueue (NI) on: Error Cluster Constant for LabVIEW 2011
Re: When Should You Use LabVIEW Classes?
I often have customers ask me if they should be using classes in in their LabVIEW application. Many of the people asking this question are long-term LabVIEW users who are new to the concept of an object-oriented development approach and they're struggling to identify how and where classes would benefit their application. If you've ever asked this question, or if you've ever wondered where in your application you would use classes, I'll do my best to shed some light on the topic and explain some of the primary benefits...
To put it simply, classes aim to make it easier to represent collections of items within software. Consider that real-world objects have attributes (colors, weight, size, etc..), and they also have things they can do (open, close, move, etc...). As you might expect, object-oriented programming allows you to define a class of objects, all of which have attributes (known as properties) and things they can do (known as methods).
Consider some contrived examples:
- Vehicles - properties: color, size, weight, occupancy, fuel efficiency, methods: accelerate, brake, roll down windows
- Cell Phones - properties: battery size, call time, weight, size, methods: place call, end call, send text message
- Network Packet - properties: port, IP Address methods: send, print string
Now, you might be thinking to yourself, "Can't I just use a cluster?" The answer is generally 'yes.' In fact, if you've recently begun developing an application that relies upon a large, complex cluster that you're passing around your application, it may be an excellent candidate for replacing with a class. This is especially true if you're passing around an array of clusters that are used to represent items that your program needs to be able to communicate and interact with. Making the switch from a cluster to a class offers several benefits - I want to highlight the following (although there are many more):
- Inheritance - so far, I've described explained that you can define a class of objects and give it properties and methods. What makes this even more powerful is the ability to define children of that class, which have the same properties and methods, as well as some of their own. They may also want to override the methods or properties of their parent class. In my list of examples, I mentioned 'vehicles.' As you can imagine, there are many different types of vehicles, some of which have very unique properties and things that they can do. If you consider 'pickup truck,' as an example, one of it's properties might be 'bed size,' which wouldn't make any sense when applied to a car or a motorcycle.
- Dynamic dispatching - If we have an array of similar objects, they likely share methods and properties. In LabVIEW, we create wrappers using VIs to access and modify these values. If we want the wrapper VI for a specific child class to do something different, we can create a VI to override the parent VI automatically. LabVIEW will automatically run the version of the VI that is appropriate for the current class. To put it simply, LabVIEW dynamically runs the VI based upon the class of the object supplied to it - this assumes that the object is a child of the generic class.
As a software engineer, it's important to be able to recognize the potential benefits and when the use of classes may make more sense. LabVIEW is almost always used to interface with hardware, so the I/O in your application may be the perfect place to start. Consider these examples:
- Hardware Abstraction Layers - This white paper on hardware abstraction layers illustrates some excellent examples of the benefits of classes and how they can be used to mitigate the risk of hardware obsolescence. Classes have been defined for certain subsets of functionality (ie: a generic Scope). When a specific instrument is connected or added, it inherits the properties and methods of the parent class, but may add additional functionality (ie: an Agilent Scope could be replaced with an NI Scope, or visa versa).
- Devices Under Test - Consider the task of testing a large number of very similar, yet slightly different devices such as cell phones. One production line may be responsible for testing a variety of different types of phones, but they almost certainly all have similar properties. The code can be written using a generic cell-phone class, but the method to execute a specific operation may require slightly different commands be sent to the test executive. This can easily be added later on without major modifications to the code through the creation of a child-class.
Personally, I recently adopted the use of classes in my projects - I went back in one of my largest projects and replaced an array of clusters with an array of classes. In my experience, the use of classes forced me to write code that has clearly defined 'ownership' - in other words, my code is cleaner and more modular because I've forced myself to say, 'this function is a member of this class - therefore, it is only responsible for operating upon the data available in this object' - this benefit is often referred to as encapsulation. This helps me avoid unnecessary coupling between sections of your application that make reuse difficult later on.
The concept of a class is not unique to LabVIEW. In fact, the use of classes is probably most commonly associated with C++, which was basically C with classes added. However, most modern programming languages, including Java and C#, heavily emphasize the use of classes. Classes were introduced to LabVIEW in 8.2, but have been continuously improved and refined since then.
For examples and illustrations of object-orientation at work, check out the following:
- Creating a class in LabVIEW
- Changing the inheritance of a LabVIEW Class
- Object Oriented FAQ for LabVIEW
- LabVIEW OO: The Decisions Behind the Design
- Applying Common C Reference Architectures to LabVIEW Using Classes
There is a lot more to be covered and discussed on the topic of classes in LabVIEW, including by-reference implementations and Endevo's GOOP toolkit. Look for more in future entries.
A final tip: there are a number of settings and options when creating and managing classes, some of which are intended for advanced use-cases. If you're having trouble figuring out how to configure something, I highly recommend consulting the LabVIEW documentation. Also, feel free to post your questions below.
Comments
