Mike K Posted February 19, 2010 Report Share Posted February 19, 2010 Hello, I have attached a sample of my first attempt at OOP in LabVIEW. My ultimate goal is to eventually turn this into a packaged menu pallet to make working with a notification icon simple an easy. I modified the .net version from NI.com into an lvclass. Basically what I am looking for here is feedback from some OOP gurus on how well I did / didn’t do. I realize there are many more things that can be added to the class, but I want to make sure I’m going down the right road before I get too far. The example is written in LV 2009. Thanks Mike Icon Example.zip Quote Link to comment
Daklu Posted February 22, 2010 Report Share Posted February 22, 2010 Basically what I am looking for here is feedback from some OOP gurus on how well I did / didn’t do. I realize there are many more things that can be added to the class, but I want to make sure I’m going down the right road before I get too far. I can't say whether you're going down the right road... it all depends on where you expect to be at the end. There's nothing blatently wrong with what you've done that I can see, though I did not execute the program and I have little experience with system tray notifications or .Net callbacks. The biggest "error" is the methods "Show FP Callback" and "Sys Tray Icon" maybe should be included as part of the class--it depends on how you want users to interact with your reuse code. Since you're making a class for other developers to use, you need to think about how you're going to present your class' functionality to them. In other words, what do you want the api to look like? The best api's are simple and intuitive. Naming your methods correctly goes a long ways to accomplishing that goal. Class methods are generally named with a verb-subject pair, such as 'Create Icon' or 'Show FP Callback.' This makes it clear to your class user what the vi does. Names like 'Callback,' 'Tray Icon,' and 'Balloon' don't identify what the method does. Consider renaming them to something more descriptive. Use the class' scoping abilities. Every public VI in your class becomes part of the class' api and it can be very difficult to change those in future versions. The 'Sys Tray Icon' vi wraps 5 other vi's that create the necessary resources and shows the icon in the system tray. Do users need to have each of those 5 sub vi's available to be called independently, or should you make them private and wrap them all in an Init method? Each method has it's advantages. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.