BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

LV OOP small tutorials and introductions in a "workshop style"


Ben wrote: 

You do not have to go all LVOOP, just start somewhere.


That is the most important step in the process. And for some reason the hardest step to take... I guess potential can be scarySmiley Very Happy.

 

In my project, I have ~250 classes in ~80 hierarchies. The hardware is "traditional" LV, because it was made before we "progressed" to OO. I did OO-ify it, but it's not used jet... 250 only sounds like a lot. A .U3D class (to put 3D in PDF) has 22 object types, so that's 23 classes. Count the type def's in your project. Each one could be a class, esp. the clusters.

 

And for the purists, each case is an opportunity for a class. But there's a limit to what is practical. Guess finding the balance is the tricky part.

 

This is not unique or new to OO, debates over what constitutes a good sub VI have been there since the very beginning.

 

Reading a good book on OO Analysis and Design (like Booch's) helped me a lot. I actually read it cover to cover before even creating a class in LabVIEW (I was a sceptic myself).

 

Hardware drivers are a typical use case, but might bring shocking improvements in some projects. Still worth the effort\training even if the class is just a fancy library. You'll probably learn to appreciate abstraction and containment. 

 

File libraries (File Reader, File Writer, think binary\ascii\versions\etc.) and Filters (avg.\high pass\low pass\etc.) can be good candidates.

 

UI's are terrible to start with, although it seems to be a first choice for a lot of people.

Message 31 of 31
(928 Views)