My "Manager" loops always have what seems like too many private methods

[GregFreeman]

When I am working on programs, I often put my parallel processes in a class called the "<parallel proc name> manager" that has a VI with its loop/process. What I am finding is that these managers will need some subVIs to keep them clean, especially in states where a decent amount of processing is done. I realize then, that these methods are always only being called only by this manager on it's loop/process VI so that said, they are always being called on the block diagram within the class. So, to me, it makes sense to make them private. But, then I end up with managers where all the methods are private, because their only real methods are wrappers to keep the BD's clean. Something seems somewhat off about this and I was just looking for people's thoughts, comments, and suggestions on better ways to handle this.

 

Edited December 31, 2012 by for(imstuck)

[drjdpowell]

Surely your class has some non-private member VIs in it, or it can’t be used by anything else.  Presumably this is you loop/process VI?  I don’t see anything wrong with it.  

[bsvingen]

When I am working on programs, I often put my parallel processes in a class called the "<parallel proc name> manager" that has a VI with its loop/process. What I am finding is that these managers will need some subVIs to keep them clean, especially in states where a decent amount of processing is done. I realize then, that these methods are always only being called only by this manager on it's loop/process VI so that said, they are always being called on the block diagram within the class. So, to me, it makes sense to make them private. But, then I end up with managers where all the methods are private, because their only real methods are wrappers to keep the BD's clean. Something seems somewhat off about this and I was just looking for people's thoughts, comments, and suggestions on better ways to handle this.

 

ManagerVIs.png

This is very similar to what I have seen as well (not 100% but close enough), I think? The "do state" vis then becomes polymorphic vis and each subclass will "overload" the parent vi in a template-ish fashion. The good thing is that the performance will be good. No dynamic dispatch, but instead optimized and/or inline vis. The "SomethingManager" must of course be known at compile time for this to work, so it can't be used everywhere.

[ned]

I don't think there's anything wrong with your approach.  Personally I wouldn't wrap the entire contents of the state in a VI, because I'd rather have some idea what's going on in the state without needing to open another VI.  Instead I'd expand the loop and put more of the code directly inside it, using subVIs to wrap individual processing sections that make sense as independent subVIs (either because you might be able to reuse that bit of processing, or because you can understand the overall goal of the state without seeing the details of that particular operation).