Is the Command pattern or the Strategy pattern more appropriate for client-server calls?

Question

I have a need to create a client-server program during a job interview, in which the client sends commands and the server processes them.

The server needs to be able to be able to change easily, meaning that there could be more command types later on.

So I implemented it using Strategy, meaning that the class processing commands looked similar to:

public class ServerProcessor
{
    Dictionary<string, Action<string>> commandsType;

    public ServerProcessor()
    {
        commandsType = new Dictionary<string, Action<string>>();
    }

    public void RegisterCommand(string commandName, Action<string> command)
    {
        commandsType.Add(commandName, command);
    }

    public void Process(string commandName, string vars)
    {
        if (commandsType.ContainsKey(commandName))
        {
            commandsType[commandName].Invoke(vars);
        }
    }
}

After I did that the interviewer said I needed to implement it using the Command pattern, but did not say why.

The Command pattern will be something like this:

public interface ICommand
{
    void Execute(string vars);
    string GetName();
}

public class ServerProcessor2
{
    List<ICommand> commandsType;

    public ServerProcessor2()
    {
        commandsType = new List<ICommand>();
    }

    public void RegisterCommand(ICommand commandName)
    {
        commandsType.Add(commandName);
    }

    public void Process(string commandName, string vars)
    {
        foreach (ICommand item in commandsType)
        {
            string name = item.GetName();

            if (name.Equals(commandName))
            {
                item.Execute(vars);
            } 
        }
    }
}

is there a reason why the Command pattern is better in this scenario, or is it just the interviewer's point of view?

possible duplicate of http://stackoverflow.com/questions/4834979/difference-between-strategy-pattern-and-command-pattern — Fuhrmanator, Jun 30 '14 at 11:38
I think the question as you ask it is too broad. I'm not sure the interviewer asked the question clearly enough, with enough requirements to justify command over strategy. Interviewers are human, too, and are notorious for asking bad questions. It's hard to set up a question right so that a pattern is obvious (without it being too obvious). — Fuhrmanator, Jun 30 '14 at 14:17
@Fuhrmanator, i've seen the question you refer to, but mine was specific, not broad as "what's the difference" second, i just want to say that this is the question i was hoping to hear, or learn my mistake. — No Idea For Name, Jul 01 '14 at 07:13

Dave Schweisguth · Answer 1 · 2014-06-30T18:40:58.857

Your two examples are very similar. They both use the Strategy pattern, not Command.

A Strategy encapsulates a process which has input of a given kind and output of another given kind. Usually the choice of Strategy depends on the input.

The Command pattern represents operations on the system as objects which are easy to construct, transmit and persist, so you can attach them to UI elements, queue them, log them, use them as the basis for undo, etc.

Your examples both take a string with the command name and another with parameters. The Command pattern would use a different class (with a common superclass) for each command, and include the parameters as properties of the object. Your examples both use Strategy to execute each command; in the first example your Strategies are Actions and in your second the Strategies are (somewhat misleadingly) ICommands. Your examples are really only different in their naming and in that one stores its Strategies in a Dictionary and the other in a List.

Now to actually answer your question: There is nothing in the problem description that requires the use of either pattern. Command is a fine pattern for client-server interfaces, because it enables the things I mentioned above, and Strategy is a fine pattern for executing Commands, so using both would be a good choice. Neither is required, however, so as far as we can tell Command is just your interviewer's choice (probably because they want to know whether you know it).

score 2 · Answer 2 · answered Jun 30 '14 at 06:03

One benefit of using Command pattern in this scenario can be to enable "undoing" some of the actions. If your ICommand interface is implemented as:

public interface ICommand
{
    void Execute(string vars);
    void Undo();
    string GetName();
}

When you create conrete implementations of this interface, adding undo logic for each type of command is easy. E.g. if the command adds some text to a document, the undo action removes that text. The context of the command is saved within the command object.

The server can add the concrete command objects to a stack after execution. In case an action needs to be undone, it's a simple matter of calling code similar to:

executedCommandsStack.pop().undo();

score 1 · Answer 3 · answered Jun 30 '14 at 15:35

1

The Command processor pattern is oriented towards a server's handling of long-running commands. This is definitely Command and not Strategy, as it's a variant of GoF Command.

Was the interview Android-oriented?

answered Jun 30 '14 at 15:35

Fuhrmanator

11,459
6
62
111

Is the Command pattern or the Strategy pattern more appropriate for client-server calls?

3 Answers3