LabVIEW Development Best Practices Blog

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 

When Should You Use LabVIEW Classes?

Active Participant

12-14-2009 3-09-34 PM.pngI 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:

  1. Vehicles - properties: color, size, weight, occupancy, fuel efficiency, methods: accelerate, brake, roll down windows
  2. Cell Phones - properties: battery size, call time, weight, size, methods: place call, end call, send text message
  3. Network Packet - properties: port, IP Address methods: send, print string

12-15-2009 10-44-57 AM.png

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):

  1. 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.  
  2. 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:

  1. 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).
  2. 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:

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.

Elijah Kerry
Chief Product Manager, Software Platform
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Comments
Member

Excellent summary of Object Oriented programming Elijah! You did include this, but it bears repeating - encapsulation is a HUGE benefit of OOP. I can't count how many projects I've come into that are passing around 30+ values in a large global cluster. It is almost impossible to figure out where those values are being acted on - especially if the original developer is no longer available. When OOP techniques are used, it is easy to figure out where the properties are being acted on since they can only be changed by the class and its children.

I truly believe that OOP is almost a necessity if you are planning any large application, especially a large application that will be going through revisions and updates in the future.

Knight of NI Knight of NI
Knight of NI

Hmmm quotes don't look right.

Nick wrote;

"

I truly believe that OOP is almost a necessity if you are planning any large application, especially a large application that will be going through revisions and updates in the future.

"

[emphesis added]

"Almost" is an important qualifier. many of us have been writing large apps for years without LVOOP so it is possible. I do agree that LVOOP has very nice features I use when appropriate.

Ben

Member
"Almost" is an important qualifier. many of us have been writing large apps for years without LVOOP so it is possible. I do agree that LVOOP has very nice features I use when appropriate.

Nice catch Ben. OOP is only one way to provide encapsulation - often it makes sense, sometimes it doesn't (look up "Ravioli Code" for the OOP parallel to Spaghetti Code).

My statement probably would have been more accurate as "Encapsulation is a necessity for any large application. OOP is often the best way to accomplish this".

Member

Great tutoral thanks for posting

Member

Nice and quick overview.

It would be great to have information about how various OOPS concepts are implemented in LabVIEW  and compare them with similar ones in C# or Java.

Anyone has info/links/etc. on the same ?

Proven Zealot

It's already in the post above. Check the links.

Member

Ooops  ... missed it. The link name was misleading, it says 'common C reference architectures.... '

Thank you.

--------------------------------------------------------------------

LabVIEW - The way programming should be

Member

@Elijah_K.. I hope you already know that Endevo GOOP has turned into LabVIEW GOOP and it's free of cost from LV2014.  Please correct it in the above content.

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.

Proven Zealot

Ajayvignesh_MV: Yes, Elijah knows about that purchase. He helped me get the right people talking to each other to make that happen. The above content was written long before that. :-) But you're right, it should be updated. Thanks for the flag!

Member

Hi guys,  I am new to oop I am still confusing where to use classes and what type of applications can I use oop in LabVIEW. for example if need to continuous monitor  temperature and display, log for this kind of applications how to use oop concepts? can anyone guide me Thanks in advance.

Venugopal
Active Participant

While a simple temperature like you are describing can be easily written without OOP, it sounds like a great place to try it out.  I suggest using OOP in lots of different settings and it will quickly become apparent where it makes sense and where it doesn't. Sometime it may be overkill, but it makes sense in a surprising amount of cases.  It particularly shines if you plan on adding to your system later.  One thing I would add is to spend a little time thinking about design and your class relationships.  That layout will make or break your design.

In your case perhaps something like:  A thermocouple class to read in your thermocouples.  A datagatherer class to collect all the data. A display class to display the data. And a logger class to log the data.  I just did that off the top of my head, so feel free to modify as needed.

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
Member

Hi Taggart,  Thanks for the reply,what about the inheritance, which one  should be the parent class?  Please guide me thanks in advance

Venugopal
Member

The basic, classic answer is: favor composition over inheritance. That's definitely good advice in this case. (You will need to use inheritance in appropriate places, but the classes Taggart describes will best relate to yet another class using a composition relationship.)