Jump to content


Photo
- - - - -

Finally trying to understand and learn Object Oriented


  • Please log in to reply
6 replies to this topic

#1 jdebuhr

jdebuhr

    Very Active

  • Members
  • PipPipPip
  • 50 posts
  • Location:Chicago Suburb, IL
  • Version:LabVIEW 2012
  • Since:1995

Posted 09 March 2012 - 03:08 PM

I have been wanting to learn this for the last couple of years but unfortunately everytime I have tried to start reading and learning, I always get a new project with a short timeline that does not allow for me to experiment.

Well, I have finally decided that noew is the time to do this, while I have a couple busy projects I have been able to find some extra time during the day to start learning.

I have already watched this webinar:
http://zone.ni.com/w...oc/p/id/wv-1766

I have started to look at the Actor Framework (https://decibel.ni.c.../docs/DOC-17193), which might be a good design platform for me to ultimately learn and use, BUT I am open to any other suggestions on what to read and look at to get a better understanding of OO.

Thanks
Jeff
Certified LabVIEW Architect

#2 ShaunR

ShaunR

    LabVIEW Archetype

  • Members
  • PipPipPipPipPipPip
  • 2,606 posts
  • Version:LabVIEW 2009
  • Since:1994

Posted 09 March 2012 - 03:51 PM

There are a few of the NI example exams coded in LVPOOP here. That'd be a good place to start since NI have equivelent examples in "proper" labview :) .

A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort. (Herm Albright 1876-1944).

Founder and general mischief maker on www.lvs-tools.co.uk.
SQlite aficionado and websocket zealot.
If it 'aint in LabVIEW, then you 'aint got a clue!


#3 Stagg54

Stagg54

    Very Active

  • Members
  • PipPipPip
  • 64 posts
  • Version:LabVIEW 2009
  • Since:2007

Posted 09 March 2012 - 03:54 PM

My recommendation would be to start small.

The actor framework to me seems like a rather advanced OOP concept. Although I really do like it.

#4 jdebuhr

jdebuhr

    Very Active

  • Members
  • PipPipPip
  • 50 posts
  • Location:Chicago Suburb, IL
  • Version:LabVIEW 2012
  • Since:1995

Posted 09 March 2012 - 04:35 PM

My recommendation would be to start small.

The actor framework to me seems like a rather advanced OOP concept. Although I really do like it.

Oh I agree, even though it is advanced, I have some understanding of how it executes. but starting small is the best way to approach it
Certified LabVIEW Architect

#5 jdebuhr

jdebuhr

    Very Active

  • Members
  • PipPipPip
  • 50 posts
  • Location:Chicago Suburb, IL
  • Version:LabVIEW 2012
  • Since:1995

Posted 09 March 2012 - 05:10 PM

okay looking at some other examples. I found this one:
http://lavag.org/top...abview-classes/

if I understand it correctly. ATM ATM.lvclass has the ATM.CTL. int he ATM.ctl there is the information for multip[le Account PWs, Names and amounts. and when a function ( deposit or withdrawl) is made the ATM object is updated allowing it to reflect the change but for each change the Object ( in this case the Atm.ctl) still needs to be sent throug a shift register to track correctly with every subsequent change. I think I have a better grasp now and may try to write something simple based off of the ATM Class model example posted.
Certified LabVIEW Architect

#6 crelf

crelf

    I'm a LAVA, not a fighter.

  • V I Engineering, Inc.
  • 5,773 posts
  • Version:LabVIEW 2013
  • Since:1993

Posted 09 March 2012 - 05:17 PM

Yeah, the actor framework is great, and certainly has it's place, but I wouldn't start with it. Start with the Factory Pattern: watch this and then this from vishots.com. Once you get comfortable with the factory pattern, I suggest you move on to the command pattern next. Once you get both of those square in your head, the sky's the limit.

crelf

 

 

Copyright 2004-2014 Christopher G. Relf. Some Rights Reserved.  This posting is licensed under a Creative Commons Attribution 2.5 License.


#7 Daklu

Daklu

    Bringing the Fu to you

  • Premium Member
  • 1,830 posts
  • Location:Seattle
  • Version:LabVIEW 2009
  • Since:2006

Posted 09 March 2012 - 07:56 PM

One of the dangers of jumping straight into the Actor Framework is you can end up writing code without understanding the subtleties or impact of your design decisions. In some respects that's what has happened with the QSM--it's super easy to write relatively complex code that on the surface looks great, but it's also super easy to create an unholy mess of things, and most people who use it don't understand what issues they should be looking out for.

From what I have seen of the AF it is nowhere near as error-prone as the QSM. It may turn out my concerns are unfounded. I actually hope that is the case. However, for better or worse the AF appears to be on the cusp of becoming the next QSM for the LVOOP crowd (meaning commonly accepted as a one size fits all solution,) and given all the crazy problems I've seen with QSM implementations that worries me.

Assuming you already understand OOP fundamentals (and it appears you do,) Head First Design Patterns is the first book I recommend for people starting to learn how to design OOP applications. After that the list opens up quite a bit. (Object Thinking, Design Patterns, The Object Oriented Thought Process, Practical API Design, etc...)


There are a few of the NI example exams coded in LVPOOP here.

Personally, I'd avoid using exam examples as the basis for anything other than learning how to pass the exam. Constraints imposed by the exam conditions (like the time limit) can lead to short-term design decisions that are not immediately clear to users unfamiliar with OOP, and those decisions might not be compatible with your requirements. I know I wasn't particularly happy with the code I turned in for my CLA exam. (Mostly... I thought the code was great on the exam I failed. I thought the code sucked on the exam I passed.)

That said, I have not looked at AQ's sample test implementation. It may be a beautiful example of how to design a sustainable LVOOP application. *shrug*

Edited by Daklu, 09 March 2012 - 08:10 PM.

  • Olivier Jourdan likes this

Certified LabVIEW Architect
Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.

Yes, the QSM is flexible. So is Jello. That doesn't make it good construction material.

There are two secrets to success:
Secret #1 - Never tell everything you know.