Is LabVIEW OOP mature enough for large applications?

[ijustlovemath]

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%?

[Ben]

---

@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

[mikeporter]

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...

[ijustlovemath]

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.

[mikeporter]

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...

[ijustlovemath]

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

[Ben]

---

@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

[Ray.R]

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.