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; } }
priv开发者_运维技巧ate 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)?
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.
Possibilities:
- action
- command
- worker
- method
I like action, personally.
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();
It sure looks like a Task
to me.
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?
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.
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
?
Task
Client code should look good with this.
//create instance of Task implementation
Task myTask = TaskFactory.CreateTask();
//Execute the task
myTask.Execute()
You could call it an Executioner. :)
Quick Answer: You already have several suggestions like "Task", "Process", "Job", even "Command".
Complementary comments: Any object has a life cycle, a "start" operation, usually the constructor, a "finish" operation, usually a "Dispose" or destructor, and unleast a single main operation like your "Execute()", but there can be more.
In you code, the constructor or destructor are internally managed by your compiler, but sometimes do some other stuff like open and closing files.
You may want to learn more about the Command Design pattern, as mention by previous answers, it seems to fit your case.
精彩评论