Loading a module as a locked attribute good or bad?

[qc4vmware]

After going through the coding guide I realize I have a ton to clean up in my workflows and actions.  One thing that I know I am doing way too much of is System.getModule() calls.  I am wondering if it is considered good practice to do something like setting an attribute to a module that gets used often throughout the workflow and passing that attribute into scriptable tasks or if it is better to set a variable each time within the scripted task?  I know there is some serialization and parsing that occurs between objects in a workflow so I want to make sure setting that attribute to a module doesn't actually end up causing me grief.

A good example of a module that gets extremely heavy use is our ServiceNow module.  So what I am hoping I can do is in the workflow set attribute snModule = our service now module.  Then pass it into a scriptable task.  Then simply call snModule.closeTask(); or whatever action I am taking with ServiceNow.  In a large workflow I might have 4 or 5 snippets where I want to call actions in this module.

[iiliev]

Well, I think there is no definite answer which option is better.

I personally would prefer to not use an attribute to share the module among all scriptable tasks but instead to use a variable locally within each scriptable task. In my opinion, the latter leads to more readable code, and you are not forced to think what the attribute value is set to, to bind it as in parameter, to make sure that it is not bound as out parameter, etc. One exception could be for some really generic modules; eg. for logging or some other often used utility methods.

But other people may have different opinion, so maybe you should try both approaches and choose whatever you feel more comfortable with.