LabVIEW
LVOOP
andon wrote:Hello, im beginner in using LV OOP and i have two questions.
1) Which components OOP missing to have been implementation OOP in LabVIEW superior?
2) How to affect the use of OOP in LabVIEW processing speed (running the program)? It can be assumed higher computational performance using OOP in LabVIEW programming as opposed to classical approach in LabVIEW?
Thanks
1) OOpers from other languages complain about not having a "by reference" option avaliable in LVOOP. This has not slowed me down and can be worked around.
2) LVOOP can be very efficient if you code correctly. With the right code constructs LVOOP operates in-place. Active Object are another feature not implemented in native LVOOP but again LV let me code around this. I have delivered apps with more than 100 Active Objects running in parallel all capable of 10 screen update/second and low CPU load (on a machine with eight cores).
But those are the negatives!
Positives?
I have been expanding my resource library using LVOOP. It turns the old fashioned idea of re-use code upside down and therefore is making me more productive.
Using the old way;
I used to have to design or find sets of sub-VIs that can be cut out for re-use. But ( damn-it 
) all too often there was something very special down at the bottom that made it useful in the orignal app but disqualified it for re-use.
Using LVOOP;
Since child classes can be used to implement the "special stuff" and children are not required when distributing the parent classes, I have made progress with re-use. Example:
A robust set of File I/O functions will include a lot of sanity checks that are often skipped (eg "Is the path valid BEFORE trying to open a file." "Has the File alredy been opened", "Are there changes that have not been writien to disk?") because we as the developers can say "that will not happen becuase..."
So I created a File class that does all of that work. It does not handle the details of the files but it does cover the high level checks. I then created a child class for TDMS files and Config files. Under these I created class for my test data (under the TDMS branch) and Hardware config (under the config branch).
When I move the the next project that requires hardware config I can re-use the classes
1) File
2) Config
3) Hardware
without having to make changes.
If I decide the data should be writtien as TDMS I will b able to re-use
1) File
2) TDMS
... and I will have to write a new class for the test data for the test.
So...
"back in the day" before LVOOP I looked at the bottom of VI hierachies for re-use.
With LVOOP I look at the top of the LVOOP class hiarchies for re-use.
I'm still learing LVOOP so if there are others with nuggets to share, please do so!
Your partner in wire,
Ben
