dmurray,
One thing that I see here is that there is room for more generalization. Basically, you have one device which may communicate via two different interfaces: serial and usb if I understand correctly. I would suspect that the voltage regulator may take several of the same inputs and provide the same outputs (possibly) regardless of the communication method; you will still have to turn things on and off, send voltages, etc its just which low level VIs will be called to accomplish what you want to do. And I guess this is where the art of OOP comes in - it is not entirely clear to me how to delegate this. Do you have have commands that are specific to the interface and you simply pass the reference to the interface as well as any data to the command object, or is there a better way of doing this? Or might this be a terrible way of doing this? I don't know.
Also, I can't remember exactly what Elijah's original demonstration looked like, but I recall that he also included references to controls on the front panel. While that might have been a good way to implement that there, it doesn't seem entirely clear why you would do this here. Why not simply have the data relevant to the command passed in with the command itself (i.e. why is that data not part of the class)? This might simplify your structure a little bit - instead of having two separate classes for turning on and off the regulator, you might simply have a single command instance that has a bool as the primary member and the regulator is turned on or off based on this bool. This would also make unnecessary the property node calls on the front panel controls.
And concerning Elijah's comment:
I did something similar to this with a much more complex system and came up with my own architecture in which I had a UI Facade which contained a single subpanel. The facade then controlled the user view through controls that allowed the user to change that view by dropping in new front panels that were all started in the background when the facade was started. Each of these front panels had very specific functionality related to discrete pieces of the system. That being said, there was some overlap in the data retrieved by the facade and the data that was needed for the different front panels. So each front panel could subscribe to some or all of the data that was received by the facade (observer pattern). I think in the end, with all the queues and events required for communication, that I ended up with a poor man's Actor Framework. So, my feeling is, that for something simple, this is an excellent idea. But, as it gets more complicated, you might consider implementing Elijah's idea with a framework that is already available rather than rolling your own. But that is probably a step farther than you want to go.
I am not sure if I said anything useful (following on someone who knows a lot more about this stuff might not be productive), but I hope it gets you thinking. And it was nice first go.
Cheers, Matt
