Online traing for OOP vs. face to face

[dacad]

I am looking hard into OOP methods for performing a significant upgrade on a test system and want to try and get some exposure realtively soon.  The instructor led (face to face) courses are not entirely convienent and so I am considering the online instructor led course and potentially the self-paced online course.

I have not had training in any other programming languages so while I understand the basic concept of OOP, I would be challenged to start using it with any effectiveness for some time without formal training.

My question is, for someone who is well versed in non-oop LabView programming, are there any opinions on the ability to absorb the training information from the different training formats for OOP in particular ?   Has anyone used just the self-paced training with no prior experience with OOP and succesfully implemented it?   Is there a good back and forth Q&A capability with the online instructor led training?

Just trying to decide what to solicit money for from my company.

Thanks for any feedback.

Doug

[Yamaeda]

My first contact with OOP was a distance course in C++ which basically meant reading and doing everything yourself with the support of a half-day lecture every 2nd week. You could probably learn it well enough from an online course, especially if you have someone to bounce thoughts and ideas with.

/Y

[crossrulz]

Let me first state that I am not an OOP person.  I have been trying to inch into it.  But the observation I have made is that you just need to get the mindset of using objects.  The LabVIEW concepts are still LabVIEW.  You just have OOP properties.  Now setting up a good OOP inheritance or design pattern can be interesting (still working through my first "complicated" inheritance tree).  But I'm convinced that it is more practice than anything.  If you are already familiar with the concepts of OOP, I would think the online training would be fine.  You always have these forums to ask questions if something doesn't quite make sense.

[AKA_TG]

daced

Your results may vary but I am similar to you in that I am for many years a procedural guy. I had much trouble learning the OOP way via just looking around

for on line information and trying to read old C++ books.

 I had no money to get fancy books like gang of four and all that, but I got lucky.

Now I understand OOP (like in really getting the 'aha' moment just before remembering it  forever)

There is one book I highly recommend to anyone who is a LV freak and wants to get a better handle on OOP and then ultimately LVOOP.

Design Patterns Explained BY Shalloway, Trott

Hurry up and put this into Google.

(I can't believe the print is complete. Its the whole book!) Surely someone is going to take this away soon.

  Almost all his examples do not use any code to demonstrate. I immediately started benefiting from reading this book.

Good luck!

[dacad]

Thanks for the input.  Started looking at the "Design Patterns Explained" but started getting lost pretty early.  Part of that is because I have read through NI's  explanation of the approach and deploment of OOP and what decisions they made regarding terminology and such.  There is some disconnect there and that made it a bit more fuzzy.

I think I need a better fundemental understanding of Objects and Classes before getting into patterns. I found the Board Testing oop example and have been playing with that.  This makes sense though I am still trying to wrap around how it implements and ties in with regular programming.

One curious caveat that I have read that bugs me is that "once a [child] class is [dynamically] loaded, it cannot be unloaded.  My ultimate goal is to apply oop to a multi-use test system where many differernt part numbers can be tested and my high level thought is that each part number will be tied to it's own class. That class is called when an order is processed for that part number and then the next order would call a different class and so on.  If the classes stay in memory even after I no longer need them, eventually it's going to start reducing my performance I am thinking.

Will keep searching and investigating and try to learn along the way.

[dkfire]

---

@dacad wrote:
...

One curious caveat that I have read that bugs me is that "once a [child] class is [dynamically] loaded, it cannot be unloaded.  My ultimate goal is to apply oop to a multi-use test system where many differernt part numbers can be tested and my high level thought is that each part number will be tied to it's own class. That class is called when an order is processed for that part number and then the next order would call a different class and so on.  If the classes stay in memory even after I no longer need them, eventually it's going to start reducing my performance I am thinking.

...

---

One thing you have to remember with OOP is the difference between a class and a object.

Look at a class as a recipe. It describes what it can do, and what data it can hold, but it does not have any data.

The object is the outcome of the class, like a bread from a recipe. The object contain data. The object is the one you are working with. But once the object is not used any more, the memory that the object and its data have used can be freed. 
The class, recipe, is still in memory, but it does not have any data, so it use little memory.

The baker can bake many breads from the same recipe, but the recipe stay the same and does not take up more storage. Once the baker sell his bread, the recipe is stil there, but the storage that the many breads are taking are decreasing.

Does it make any sense?

[crossrulz]

---

dacad wrote:I think I need a better fundemental understanding of Objects and Classes before getting into patterns. I found the Board Testing oop example and have been playing with that.  This makes sense though I am still trying to wrap around how it implements and ties in with regular programming.

---

Look in The Object Oriented Thought Process.  I recently just read through it and it silidified many concepts for me.  But again, I'm still trying to change my mindset.

[AKA_TG]

Thats ok but to be fair I don't think anyone can get OOP in a few hours. The concepts have to be learned over time with bedtime reading so to speak.

At least that is the way it worked for me.

I read that book every night and after awhile the underlying concepts started to sink in. Implementation details of LabVIEW are not as important,

In fact, starting with LVOOP or any programming language is probably not going to let you learn the stuff you need to learn. It is the concepts more than the implementation details that are the most important.

LIke I said. I was a procedural guy for over 20 years so it took some time to internalize the new paradgim.

I would still recommend you give it a shot and spend more time with the book.

[dacad]

With the baking analogy, I guess I would expect to put the recipe away when I'm done baking the bread and get the next recipe out so I don't have multiple recipes floating around the counter.   I do get your point though as it relates to memory consumption.  I take it as the class really acting as a definition while the object(s?) of that class containing all the action.

For the book, I am not giving up on that, I just think I need to run parallel with some more specific class / object understanding as it relates to LV.   I can proceed much better with a topic if I understand the underlying mechanics of implementation. In other words, being a very visual person, I can go WOT as long as I can visualize the concept in some implemented form.

I can see pretty quick though that this method of programming is going to force more upfront planning and likely a visual layout of the class structure(s).

Will keep plugging away and hopefully can get that moment of insight sooner versus later.

Thanks....

[dkfire]

---

@dacad wrote:

With the baking analogy, I guess I would expect to put the recipe away when I'm done baking the bread and get the next recipe out so I don't have multiple recipes floating around the counter.   I do get your point though as it relates to memory consumption.  I take it as the class really acting as a definition while the object(s?) of that class containing all the action.

 ...

---

You are right, but this is where LabVIEW acts different from others. In LabVIEW we can't remove/unload the class from memory once it is loaded.

The object don't contain actions, that is the class. The objects contain data.