views:

84

answers:

4

I'm struggling for a pattern here. I have quite a few tasks that need to be run, but only need to be run once if they haven't been run before. Everything right now is handled by if/then, booleans and a hashtable. There are also nested children of the same effect (if/then, boolean) so their parent if/then, boolean isn't set to true until the very end.

In .NET, is there some kind of code pattern or class for this that makes it simplier/clearer/less code, or am I over-thinking it and this is exactly the way needs to be done?

P.S. feel free to add better tags to this post, I wouldn't know what to add to make it more descriptive if there is a term out there

+5  A: 

If you're using .NET 4.0, the Lazy<T> generic might be the solution to what you're describing, because it evaluates its value at most once.

I'm not sure I exactly understand your use case, but there's no reason you couldn't nest Lazys together to accomplish the nested children issue.

Mark Rushakoff
This looks promising, I'll research it some more.
Otaku
After looking at all the suggestions, this is the perfect one for my needs. Thank you!
Otaku
+2  A: 

I'm not exactly sure what you're talking about, but a helpful pattern for complex chained logic is the rules engine. They're really simple to code, and can be driven by simple truth tables, which are either compiled into your code or stored as data.

Dave Markle
Interesting, I'll take a good look at that.
Otaku
+2  A: 

Create a private static variable, create a read only property to check for null on the private variable, if the variable is null instantiate/initialize and just return the private variable value. In your implementation code reference the property, never the private variable.

Tahbaza
I'm not exactly how that is different from what I'm doing today, minus the hashtable. Is it different from a bunch of if/thens?
Otaku
Only in that there is only one if then required rather than one in each point in your code where you need to use the resource
Tahbaza
+6  A: 

I don't know how your tasks are coded, but it seems that they could be encapsulated in commands, which would then be put in a queue, or some other data structure. Once they are dequeued, their logic is checked. If they need to run, they are executed, and they're not put back in the queue. If their logic says that they shouldn't run, they're just put back in the queue to be able to run later.

Your interface would be something like:

public interface ITaskSink {
  void AddTask(ICommandTask task);
}

public interface ICommandTask {
  bool ShouldRun();
  void Run(ITaskSink sink);
}

Tasks could also be able to add other tasks to the data structure (so Run takes an ITaskSink as a parameter), covering your subtask creation requirement. A task could even add itself back to the sink, obviating the need for the ShouldRun method and simplifying your task processor class.

Jordão
Great example, I'll research the commands some more.
Otaku
Really appreciate this Jordão. Mark's was more closely aligned to what I'll be going with. But I learned something new from you that will come in handy in the future. Wish I could accept more than one answer!
Otaku