oop use and not use

[slipstick]

Hello, I've been using LabVIEW for a couple of years now and have run across some references to OOP. I have read a little of the help file on it and some stuff on the forum. I have a basic question about it I'd like to get answered before I get too much further into it. Fundamentally, Why? What does OOP give the programmer that he can't do (or is really hard to do) in regular LabVIEW? It seems to me it is a different kind of cluster. So I must be missing something.

[Jason_P · Accepted solution]

You're right - in LV an object is really a cluster.  But there is more to it than that... 

In the interest of full disclosure - I've written exactly one app using OOP.  It was an app that utilized a set of VISA drivers I wrote for a line USB spectrometers.  Each type of spectrometer had similar functions, but required different hex codes to execute the same functions.  In addition, the format of the data returned by each spectrometer differed. 

I had exactly the same concern as you do before I started.  I decided to use LVOOP for one reason:

Because I knew I'd have to extend the drivers in the future.

I created a parent class called USB Spectrometer that had subVIs for all the common functions.  I created a child class for each of the types of spectrometers.  In the child classes, anywhere the commands differed between spectrometers, I overroad the parent class subVI.  In the future, when I need to add another type of spectrometer, all I need to do is create another child class and override the same subVIs.  99% of my code won't need to change at all...

In short - OOP won't offer any capabilities you don't already have.  In my opinion, it is more like an organizational technique that can be used to help manage code that you may someday have to extend.  In my personal experience, it made me really think about the structure of the app and forced me to write tight, highly modular code.

LVOOP was a little painful to learn (I had to work a bit to understand how to use dynamic dispatching).  But having used it once, I expect to use it again - I even look forward to it.  However, it's not a cure all... it takes effort to implement, so I would tend to avoid it for small (and even some mid) scale applications. 

Jason

[Ben]

---

Jason P wrote:

You're right - in LV an object is really a cluster.  But there is more to it than that... 

In the interest of full disclosure - I've written exactly one app using OOP.  It was an app that utilized a set of VISA drivers I wrote for a line USB spectrometers.  Each type of spectrometer had similar functions, but required different hex codes to execute the same functions.  In addition, the format of the data returned by each spectrometer differed. 

I had exactly the same concern as you do before I started.  I decided to use LVOOP for one reason:

Because I knew I'd have to extend the drivers in the future.

I created a parent class called USB Spectrometer that had subVIs for all the common functions.  I created a child class for each of the types of spectrometers.  In the child classes, anywhere the commands differed between spectrometers, I overroad the parent class subVI.  In the future, when I need to add another type of spectrometer, all I need to do is create another child class and override the same subVIs.  99% of my code won't need to change at all...

In short - OOP won't offer any capabilities you don't already have.  In my opinion, it is more like an organizational technique that can be used to help manage code that you may someday have to extend.  In my personal experience, it made me really think about the structure of the app and forced me to write tight, highly modular code.

LVOOP was a little painful to learn (I had to work a bit to understand how to use dynamic dispatching).  But having used it once, I expect to use it again - I even look forward to it.  However, it's not a cure all... it takes effort to implement, so I would tend to avoid it for small (and even some mid) scale applications. 

Jason

---

For the most part I agree with what Jason posted but want to point out some bonus points that LVOOP has.

1) I can deploy new drivers support to an exsting LV app with having to rebuild it. LVOOP can use code that we have not developed yet using Dynamic dispatching.

2) LVOOP extends your re-use library because rather than looking at teh bottom of a VI hiearchy (sub-VIs) for re-use stuff you now look at the top (parent classes).

Ben

[tbob]

I just recently created a project using LVOOP.  The project consists of having a cluster of data for each device that was being tested.  As of now, the cluster contains a serial number and a measurement data array.  I could have just built the cluster, and then used an array of that cluster.  However, I may want to (and probably will) add more elements to the cluster later on.  This would require changing the cluster in many vi's.

Using LVOOP, I created a class instead of a normal cluster.  The class is still a cluster but the way it is handled is quite different.  Then I create an object of that class for each device that was tested.  I created functions for the class such as create new, get data, put data.  In the future, whenever I decide to add more elements, I just modify the class, click on Apply Changes, and every subvi (function) that uses the class gets updated automatically.  I don't have to modify the clusters in each vi.  I will have to modify, the get and put functions slightly to provide for the new element.  But the biggest advantage is that it forces me to program with modularity.  Small modules do the work.  It is easy to create and easy to follow.  Anyone can pick up where I left off and maintain the code.  I plan on using LVOOP more in the future.

[slipstick]

Ok, all your comments helped. I spent some time and have a general idea of how it will help my programming. What I need now is something that bridges the gap between a set of criteria on paper and the classes, methods and other things in a project. Kind of a 'where do I start?'

I am going to pick up a book today on the concept of OOP, not language-specific.

Thanks all!

[tbob]

I would make sure that all items in the class are defined, then create the class in labview.  Almost like creating a cluster of elements.  It is pretty elementary. 

Make sure all of your methods (functions) are defined, like create new, get, put, close, destroy, whatever else.  Then start coding the methods using objects of the class.  The project explorer will hold everything together.  This makes it easy to add more functions and/or to add more elements to the class.