EDIT 2: I was asked by OP to explain more situation where there is some data to pass between preprocessing function and main function. There are at least two possible solutions. First is to implement factory other way, so this is no longer using static instances of commands but creates a new one for each call:
public static class CommandFactory2
{
public static BaseCommand GetCommand(string invokedVerb)
{
switch (invokedVerb)
{
case "barcode": return new CommandA();
case "addblankpage": return new CommandB();
// ...
}
return null;
}
}
The only remaining thing is to add some fields / properties to BaseCommand or specific Command and just share values between methods of the class, like:
class CommandC : BaseCommand
{
private string _extraValue = null;
protected override void ExtraStuff()
{
base.ExtraStuff();
_extraValue = ProcessExtraValue();
// I have to set some extra parameters here...
}
protected override void DoRealStuff(DocWrapper doc)
{
// Doing my other stuff here!
switch (_extraValue)
{
// ...
}
}
private string ProcessExtraValue()
{
//...
return "";
}
}
The second approach would be suitable if you always produce same intermediate data, so then you do not alter Factory but rather BaseCommand interface and children, like:
public abstract class BaseCommand
{
protected BaseCommand()
{
}
public void Process(StuffOptions options)
{
Logging.Log("here is a bunch of logging");
// here sometimes there is some action-specific code but not often
ExtraData data = new ExtraData();
ExtraStuff(data);
using (DocWrapper doc = new DocWrapper(options.File)) // this is in all actions
{
foreach (int page in doc.GetPagesToModify(options.Pages)) // this is in most actions
{
// call some stuff on the doc instance
DoRealStuff(doc, data);
}
doc.Save(options.OutputFile); // this is in all actions
}
}
protected abstract void DoRealStuff(DocWrapper doc, ExtraData data);
protected virtual void ExtraStuff(ExtraData data)
{
}
}
And then you just fill this ExtraData
class with whathever proeprties you wan't to share.
I would personally prefer first one, as it is more elastic and introduces extra stuff only when this is required (ie. only inside these commands that need this). However drawback is if you are planning on intense processing - you will be creating new instance of command class every time you are going to use it...
Eventually, this can be solved on factory level - implement each command creation the best way that suits it better - even create deeper command inheritance to distinguish different behavior. But now I went too far (and broke SOLID a bit), so let allow me to finish at this point :P