Search the Community

Hi Background: I'm diving into this "OOP" stuff right now. My background is NOT CS (Computer Science) but instead electronics and aerospace design. Diving into the deep end of the pool, I'm still in that happy ignorant state of "this is fun" right before I'm realizing I can't swim and that I might drown, or that I can probably stay afloat, but I'm not at all sure what direction I need to swim in to get to shore, or to get to friendly shores... you get the picture I'm sure. (That said, I'm very familiar with "standard" LabVIEW, including RT and FPGA, and have worked full time with LabVIEW for over 2.5 years, I have the CLD and CPI certification for LabVIEW. I currently use LabVIEW 2011.) Anyway. I've read white papers and articles (How to Mitigate Hardware Obsolescence in Next-Generation Test Systems, LabVIEW Object-Oriented Programming: The Decisions Behind the Design, LabVIEW Object-Oriented Programming FAQ), watched presentations and seminars (Data Communication in LabVIEW Technical Seminar), read forum posts(Techniques for componentizing code), looked at exercises and examples (Object Oriented Design Patterns Technical Manual and Exercises, Software Engineering with LabVIEW, ) and poured over blogs (Worker pool – a design pattern for parallel task execution in LabVIEW, Unlimited parallelism & concurrency with recursive dataflow, Eyes on VI's) and I still find myself still confused on a lot of "core" things (that may only come with experience?). I certainly don't claim to understand all of the linked material; I'm still toweling off from drinking from that fire-hydrant, but I wanted to show that I have done some studying of the topic and figured that if I put at least some of the links up here, it may even help others like me find good links on this OOP beast. While a lot of this went over my head, I find myself applying and using the term "complecting" and "complect" a lot when thinking about what I want to do and what I don't want to do and for those with time to kill, its a very interesting talk that points out some things regarding "easy" and "simple" that I think is all too commonly forgotten in todays work.. go on.. I'll wait while you watch/listen to it.. you know you want to click it .. go on, its Simple Made Easy its good for you. I'm still in the planning phase, having been blessed with the time to take it slow and do it right (while maintaining some legacy code on the side while I'm incubating this next generation version), so I'm not committed to any particular architecture or method (including OOP). Key is that I (or <we>) will need to support this platform for years while adding new features etc. along the way. So I'm pretty sure that OOP is the right choice.. but how to organize and implement it. Since I can't hope to learn everything in one post here is: MY QUESTION FOR THIS POST: How do you know what to put in a class and where to draw the line, both in terms of having too many things in one class, and having to granular (huge amount of classes for the littlest things)?? Example: I have an instrument. Its a peculiar type of instrument with a little bit of a personality (that changes with firmware). Do I create a giant class called myInstrument and create methods for everything I need to do (and get) from the instrument? Or do I make smaller classes for "configure" and "acquire" and gather them all up in another class? -The instrument communicates over USB or TCP/IP, surely that should be a layer/class of themselves? (class within class). But then we get to things like the "personality" of the instrument: depending on configuration of the instrument, from when I "start" an acquisition to when I can request the data, it could be anywhere from 10 seconds to HOURS. Do I poll the instrument ready flag in a method or outside of the class/object? (inside, yes, right? to protect access to it, or poll it outside, but by using calls to class method?) Do I have methods that other parts of my software can call to "get status" of the instrument? (wouldn't that complect my software un-necessarily since all sorts of places in the code could be structured to depend on the status of the instrument, when in reality all they probably care about is getting updated data at the end with no regards to the status of the instrument at any given time?) So, then, when the instrument does return data, the data needs to go to all these things, like the file logger (plug-in class?) and the graph history display (another class) only on windows systems, but not cRIO/RT systems, update modbus memory maps (plug-in, some systems, not always) and UPC (plug-in, some systems not always) etc. How should this sharing of data be done? Other parts polling methods of the instrument class? instrument private method publishing data to named queues? (this last seems like the right choice to me but is it in the spirit of OOP??) Then (finally), I need to be able to spawn an unknown (at edit time) number of these instruments and I need to be able to run this code on cRIO OR Windows. If I write the instrument class, I think I can spawn copies of it dynamically... should I put the instrument inside of actors (or is the class itself the actor) in the actor framework? Should I use dynamic events to broadcast stops? What about error handling? A class of itself? An actor? what about the complecting that occurs if you do that? (everyone will be calling the error handler from within itself, causing complecting to happen.. what about just having loops push errors and warnings onto a named queue and have a daemon handle it? Can I do that while using OOP? Is the dameon then a class, or is the daemon the architecture and it uses classes inside of it? As evident by my "question" I am a little overwhelmed when it comes to thinking about what a class/object is and what should live "inside" of it, and what should go around it on the outside. Old habit also keeps screaming QSM QSM QSM and "Action Engines" (aka functional globals) over and over since my brain already knows those tools... I THINK maybe the point is that you define classes and make objects but you tie them all together in "normal" structures like QSM's and possibly even "Action Engines"? Thank you for your time, and I hope for some encouragement, clarifying questions, guiding hints and tips or just about any response you care to share with me!