views:

106

answers:

9

I have designed the following class that should work kind of like a method (usually the user will just run Execute()):

public abstract class ??? {
    protected bool hasFailed = false;
    protected bool hasRun = false;

    public bool HasFailed { get { return hasFailed; } }
    public bool HasRun { get { return hasRun; } }

    private void Restart() {
        hasFailed = false;
        hasRun = false;
    }

    public bool Execute() {
        ExecuteImplementation();
        bool returnValue = hasFailed;
        Restart();
        return returnValue;
    }

    protected abstract void ExecuteImplementation();        
}

My question is: how should I name this class? Runnable? Method(sounds awkward)?

+1  A: 

Usually the Command pattern uses classes with an Execute() method. Is that more or less what you're trying to accomplish? I guess it's close enough for me; I would call it a Command or Worker or something similar.

Do you know about BackgroundWorker?

Cory Larson
Yes, I know BackgroundWorker. But this has nothing to do with Threads. I just want to have a class that allows different implementations of its Execute() method. It must return a boolean value as result and in child classes it can also have different return values in the form of public getters in the class!
devoured elysium
I think Command or Action (as JRL suggested) would suit you then.
Cory Larson
+3  A: 

Possibilities:

  • action
  • command
  • worker
  • method

I like action, personally.

JRL
I don't like action, mainly because it conflicts with a pre-existing .NET Framework delegate (and one which is very heavily-used, to boot).
Aaronaught
Yes, I like Action too, but as said by Aaronaught, it ends up being a bad choice as it conflicts with System.Action.
devoured elysium
Command is the one for me, but I would call it better CommandBase as it is abstract
Jhonny D. Cano -Leftware-
+1  A: 

The .NET Framework already has a class that does this (several, actually). They're called delegates.

If it's really doing a lot more than just executing a method - performing error handling or that sort of thing - then name it for what it actually does, not how it's implemented.

If you absolutely have to implement a totally generic and abstract class that does nothing but encapsulate an arbitrary method and some sort of success/failure status (why?), then... task, worker, command, instruction, request, activity, etc... pick any of the above, they all mean pretty much the same thing in this context.

Aaronaught
The thing is that child classes can be way more complex and besides returning success/failure I want to return additional information in the form of public properties.
devoured elysium
@devoured: That's exactly the problem that `EventHandler`-derived classes and the event pattern are already intended to solve. I don't see much of a use for this base class, but if you're sure you know what you're doing, then I offered a number of naming suggestions above.
Aaronaught
+3  A: 

Naming a class is all about a good design. You have to know which use cases this class will be part of, which responsibility it will take and what collaborations will this class take part in. Naming class without context can only do harm. Naming class after a pattern just because the pattern uses similar names is even worse, because it might confuse any reader who knows something about patterns, whcih is exactly opposite of what patterns try to achieve - name common decisions/solutions/designs/etc... Your class can be Runnable, Executable, Method, Procedure, Job, Worker, RestartableExecutor, Command, Block, Closure, Functor and virtually pretty much anything without further information.

Gabriel Ščerbák
+2  A: 

I guess a good question to ask yourself would be what you are executing. Then you might get an idea of what to name it.

For example, if you are executing a file and folder scan, you could name the class FileAndFolderScan.

FileAndFolderScan.Execute();
Zach Johnson
+2  A: 

It sure looks like a Task to me.

280Z28
+1  A: 

At my work we were stuck on .NET 2.0 for a while (pre-Action and Func delegates) and I had been using a bunch of overloaded generic delegates with the same signatures called Runner and Returner. Seems to me you could go with Runner and have a pretty clear self-describing class.

Alternately, why not just go with something like Executable or Executor?

Dan Tao
A: 

You could call it an Executioner. :)

Daniel Plaisted
+1  A: 

Task

Client code should look good with this.

//create instance of Task implementation
Task myTask = TaskFactory.CreateTask();

//Execute the task
myTask.Execute()
this. __curious_geek
Yes, that's what I ended up using :)
devoured elysium
@devoured: you might want select any of the answers as accepted.
this. __curious_geek