Jump to content

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


Recommended Posts

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.

 

post-15770-0-91189800-1356985864_thumb.p

Edited by for(imstuck)
Link to comment
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.

 

attachicon.gifManagerVIs.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.

Link to comment

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).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.