Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My application has a number of different asynchronous 'things' that it performs:

  • There are things that fire off a schedule (every 5 minutes)
  • There are things that are fired when a user clicks a button
  • There are things that are triggered by an incoming web service call

I use the terms like this:

  • Scheduled things = Jobs
  • User-triggered things = Tasks
  • Web service-triggered things = Operations

Tasks are quite complicated, so they're implemented using a hierarchy of different objects which I call Activities (operations and jobs may also begin to use these Activities as their building blocks).

I feel like I might be using the wrong terms - for example, would you expect something that happens every 5 minutes automatically to be a Job or a Task? Is there an industry standard for this? All of the words seem to mean the same thing.

share|improve this question
    
Why make them all different if they are basically the same thing? –  CaffGeek May 30 '12 at 21:55
    
Events are more standard term for UI input. –  Garrett Hall May 31 '12 at 0:07
    
You forgot to mention process, thread, service, daemon, helper and probably many others. –  mouviciel May 31 '12 at 8:04
    
What do you mean by: Schedule things = jobs? Could you provide the context where you are using this terminology? –  Emmad Kareem May 31 '12 at 8:44
add comment

closed as not constructive by Jarrod Roberson, Mark Trapp, Matthieu, Jim G., Walter Aug 26 '12 at 14:12

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

What you're describing is event-driven programming. If for no other reason than to avoid confusion, I'd make it all generic:

  • Your application receives events
  • Your application responds to events with event handlers (or throws an exception).

As such, you avoid confusing terms (they may mean something to you, but won't to the next person reading your code) and having the need to append to those terms as you encounter new "things" that need to be handled.

Of course, there are various ways of implementing these (typed events, untyped events with payloads, etc etc), but that's an implementation detail.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.