Why use LVOOP? Answer scalable code

[mfitzsimons]

One of the key advantages that are overlooked when choosing to use LabVIEW Object Oriented Programming (LVOOP) or OOP techniques is scalability.  We all remember when we wrote that program to communicate with that one device.  For this example lets say it was a DMM.  After it was all done came the request to now make it talk to 10 Digital Multimeter Meter (DMM).  Now the simple code that had a few variables is out of control.  There are new variables to add and maintain and trying to manage these can be difficult.

Scalability is the ability to add 1 to N devices to your software and have it easily adapt to the change with minimal software modification.  What makes this possible in OOP is that the data (variables) is part of the class.  As you add additional instances (additional same classes) of the class you get the data and the methods to operate on the data.

The example below contains a very good example of scalability.  It is a stopwatch class that can start, stop, and get lap times for as many stopwatches as you want to add.  I have seen this example done before but wanted to recreate it with LVOOP.  It helped me see a key benefit to using this programming technique.  Yes, you could do this without OOP but imagine if your class was significantly more complex like testing a cell phone.

See attached example: TestMultipleStopwatch.vi in LV 8.20.  This is one of many reasons why you should upgrade to LV 8.20 and use LVOOP capabilities.  I wrote this program because I could not find a good example of scalability and LVOOP.

[smercurio_fc]

I don't think you need to be selling the advantages of OO. OO has been well established as a superior way of programming in most instances. However, it's not the panacea many programmers claim it is. There are instances when OO doesn't really offer any advantage over older methods. That said, I think the issue with embracing LVOOP is its actual implentation of OO principles. NI made certain decisions on what components of OO to implement. They believed the components they implemented were the most important. That's debatable, and my objective in this response is not to start a flame war. My objective is to say that LVOOP isn't the best implementation of OO principles that I've seen. For instance, I'm looking at the project I'm currently working on and really trying hard to see how I could use LVOOP for it. Believe me, I've tried several times to do this. To be honest, I'm hard pressed to come up with overriding reasons to do so. Why? Because I already designed the project to be moderately scalable in the first place without OO, and I can't do some things that I want to do with LVOOP that I would be able to do with "standard" OO. Now, this doesn't mean that LVOOP is "worthless". I am not saying that at all. All I'm saying is that having programmed in C# and VB.NET, I can see the deficiencies of LVOOP and wonder how useful it would be for really complex projects. My main concluson: It's better than nothing.

Perhaps I am not as specific as I need to be, so I say that there's a far better discussion on LVOOP over at the LAVA forums. I highly recommend reading it for those who are looking into OO and LabVIEW.

[Broken_Arrow]

I realize I'm two years late to the party, but I just stumbled on this and thought it was pretty swell. Thanks Mat.

[Slyfer]

I agree with smercurio.

If C# value 10 points (in term of "Object Oriented paradigm"), LVOOP value 1.5/2

Mark.

Let's wait 2 more years LOL. Look at Tiobe Index programming language. Labview is 0,2% and the reason is that it is strictly inferior to other languages/packages.

It's OK only if you buy NI hardware (say compact RIO), and you want to make some "WOW" to commercial agents (not to engineers of course) saying "I did this in 2 days".

Push forward, and it's game over with labview. Still today at 8.6 release, after more 20 years of developing. I use it only because my company forces me, as soon as I find another work I will finally be free from this crap piece of software

[Ben]

---

Slyfer wrote:

... I use it only because my company forces me, as soon as I find another work I will finally be free from this crap piece of software

---

I used to work with another developer that absolutely hated chocolate. In my book chocolate is "Vitamin C" and I seldom go a day without it. To try to beter understand each other she brought in some candy for me to try and I was reaching for my antacid tablets just smelling it. So we never came to an agreement on what flavor of cake was best.

For me LVOOP has become part of my standard tool-box. The code I have developed using it has open up new windows of re-use potential I never realized without LVOOP.

So in my book LVOOP is chocolate icing on a chocolate layer cake.

I hope that you find the oppertunity to get your teeth into something more appealing to you.

Bon apeptite* !

Ben

* That is probably spelled wrong since it is French and I never did figure out that language.

Message Edited by Ben on 05-18-2009 08:55 AM

[Thoric]

I know some people who will never switch to LVOOP, citing it as too alien to their understanding of LabVIEW coding and too much of a leap in programming philosophy to adopt. I also know others who'll always attempt to code in LVOOP, whenever an opportunity arises, because they just can't code without it. Both are clearly extremes. I personally have not yet had an opportunity to really get my mind around LVOOP and understand "the point" - until I read the author's post and examined his attached Stopwatch project. This example clearly shows the benefits that a LVOOP implementation can provide. Thank you Slyfer for making this thread bump to the top!

Thank you also to smercurio for his objective view on NI's implementation of OOP. As I've not experienced OOP before, I've no comprehension as to it's implementation in other languages and consequently "don't know what i'm missing" in terms of NI's omissions with OOP. But for me: it cannot take away, it can only provide more than I already have... 

I look forward to giving this a go...

[smercurio_fc]

I haven't had chocolate in so many years I've almost forgotten what it tasts like. Just another item in the list of stuff I can't eay anymore. Oh well.

I get the feeling from Slyfer's response that his beef is more to do with LabVIEW in general, rather than LVOOP in particular. But that's just an impression.

For me, I haven't given up on LVOOP, and never actually did. Still haven't implemented it though. I suspect that I'm still a bit too much of a text-based weenie at heart. 

[tst]

Ooh, flaming... 

---

Slyfer wrote:

Labview is 0,2% and the reason is that it is strictly inferior to other languages/packages.

---

No, the reason is that it is generally more domain-specific and that it's expensive.

---

It's OK only if you buy NI hardware (say compact RIO), and you want to make some "WOW" to commercial agents (not to engineers of course)

---

I've done quite a few systems without any NI hardware (which took more than two days) and which people (including other people from the relevant field) were impressed with. LabVIEW has advantages and disadvantages, like anything else.

---

Still today at 8.6 release, after more 20 years of developing.

---

Windows, after roughly 20 years, is only at version 7.

Apple has been making computers for 30 years and the Mac for 25 years and they're only at version 10. What does the version number have to do with anything?

If it helps to ease your mind, LabVIEW will be at version 2009 in a couple of months.

It's legitimate not to like something, but you should at least have valid reasons for it.

[JB]

---

Ben a écrit:

Bon apeptite* !

 

* That is probably spelled wrong since it is French and I never did figure out that language.

---

Indeed, the correct spelling is "Bon appétit !"

[nitad54448]

Bon apeptite* !, is good if you are talking about antacids