LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is LabVIEW OOP mature enough for large applications?

Mike,

 

My end goal is exactly as you stated, I want this project to be readable, maintainable, and extensible. When you say that people went 100% OOP, do you mean that they didn't use state machines and the like? What's the difference here between 100% OOP and, say, 50%?

0 Kudos
Message 11 of 18
(1,497 Views)

@ijustlovemath wrote:

Mike,

 

My end goal is exactly as you stated, I want this project to be readable, maintainable, and extensible. When you say that people went 100% OOP, do you mean that they didn't use state machines and the like? What's the difference here between 100% OOP and, say, 50%?


I would suggest you start with the components first and then move to the Top Level VIs in LVOOP. While I must confess I am not familiar with all of the oficial names of OOP Patterns, most of the most useful patterns adress hwo to structure stuff "lower in the hiarchy".

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 12 of 18
(1,488 Views)
Actually, I wasn't even thinking of that application -- but you're right that was a learning experience hindered in no small degree by the OOP bugs still present in LabVIEW. And it did some really cool stuff.

On a brighter note though: How 'bout them Pens!

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 13 of 18
(1,484 Views)

Ben,

 

I see what you mean. I have about ~1500 VIs between the 3 applications, so I definitely won't be changing all of them to OOP. The guts will stay largely procedural, with the top level stuff being OOP for maintainability and extensibility. Thanks for cleaning that up.

0 Kudos
Message 14 of 18
(1,476 Views)
I will use OOP where it simplifies the code, like providing abstraction layers. This is what I call explicit OOP.

For the application's main structure I use "conventional" LabVIEW programming. I call that code "implicit" OOP because while it doesn't incorporate classes, LabVIEW is at its core an object oriented environment. This is why when people as me when I started doing OOP in LabVIEW I tell them 1986.

The thing to remember is that object orientation is a lot more about a way of thinking than it is specific technologies.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 15 of 18
(1,473 Views)

Mike,

 

Would you mind taking a look at my other thread, where I go into more detail about what specifically I'm using OOP for? Here's the link: http://forums.ni.com/t5/LabVIEW/OOP-Design-Decisions-Inheritance/td-p/3297445

Message 16 of 18
(1,465 Views)

@mikeporter wrote:
Actually, I wasn't even thinking of that application -- but you're right that was a learning experience hindered in no small degree by the OOP bugs still present in LabVIEW. And it did some really cool stuff.

On a brighter note though: How 'bout them Pens!

Mike...

I do not think that application will even run in a modern version of LV. Stephen took a look at the code and "FIXED" holes we had exploited.

 

The only major limitation that I see in LVOOP as it stands today is that we have no method to destroy instaciated classes.

 

Example:

 

General Purpose Game program. Will allow playing any game.

 

Implement that using a Factory Pattern that spits out an instance of a game the user chooses. If the user keeps choosing different games the previously played games stay in memory. Only way to destroy them is kill the applcation.

 

So a Factory pattern i a loop will run out of memory givien enough iterations.

 

I hd to resort to "recycling" objects in one application where I was plotting shperes in 3D to represent flaws detected by an ultrasonic test. I could not just create a new "surface" (a class) composed of multiple "Points" becuase the 10,000 points from teh previous scan stuck around in memory when I loaded a new "Surface". In my case I had to re-use the surface and re-use the "Points" I had previously used. I only added new points (Factory Pattern) only when I needed more points than I already had in memory.

 

A proper "destroy" would have made that code SOOOOOO much simplier.

 

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 17 of 18
(1,451 Views)

I would say yes.

 

We've been using LVOOP in large projects since 2008 (I think).  Unless there is an obvious reason, I would not consider anything else for larger projects.  They all work quite well.  Plus our code using LVOOP has evolved over the years.

Message 18 of 18
(1,337 Views)