C++ Command Pattern Design – Best Practices and Examples

cdesigndesign-patterns

I have this old implementation of the Command pattern. It is kind of passing a Context through all the DIOperation implementation, but I realized later on, in the process of learning and learning (that never stops), that is not optimal. I also think that the "visiting" here doesn't really fit and just confuses.

I am actually thinking of refactoring my code, also because a Command should know nothing about the others and at the moment they all share the same key-value pairs. It is really hard to maintain which class owns which key-value, sometimes leading to duplicate variables.

An Example of use case: let's say CommandB requires UserName which is set by CommandA. Should CommandA set the key UserNameForCommandB=John? Or should they share a common UserName=John key-value? What if the UserName is used by a third Command?

How can I improve this design? Thanks!

class DIParameters {
public:
   /**
    * Parameter setter.
    */
    virtual void setParameter(std::string key, std::string value) = 0;
    /**
    * Parameter getter.
    */
    virtual std::string getParameter(std::string key) const = 0;

    virtual ~DIParameters() = 0;
};

class DIOperation {
public:
    /**
     * Visit before performing execution.
     */
    virtual void visitBefore(DIParameters& visitee) = 0;
    /**
     * Perform.
     */
    virtual int perform() = 0;
    /**
     * Visit after performing execution.
     */
    virtual void visitAfter(DIParameters& visitee) = 0;

    virtual ~DIOperation() = 0;
};

Best Answer

I am a bit worried about the mutability of your command parameters. Is it really necessary to create a command with constantly changing parameters?

Problems with your approach:

Do you want other threads/commands to change your parameters while perform is going on?

Do you want visitBefore and visitAfter of the same Command object to be called with different DIParameter objects?

Do you want someone to feed parameters to your commands, that the commands have no idea about?

None of this is prohibited by your current design. While a generic key-value parameter concept has its merits at times, I do not like it with respect to a generic command class.

Example of consequences:

Consider a concrete realization of your Command class - something like CreateUserCommand. Now obviously, when you request a new user to be created, the command will need a name for that user. Given that I know the CreateUserCommand and the DIParameters classes, which parameter should I set?

I could set the userName parameter, or username.. do you treat parameters case insensitively? I wouldn't know really.. oh wait.. maybe it's just name?

As you can see the freedom you gain from a generic key-value mapping implies that using your classes as someone who did not implement them is unwarrantedly difficult. You would at least need to provide some constants for your commands to let others know which keys are supported by that command.

Possible different designs approaches:

  • Immutable parameters: By turning your Parameter instances immutable you can freely reuse them among different commands.
  • Specific parameter classes: Given a UserParameter class that contains exactly the parameters I would need for commands that involve a user, it would be much simpler to work with this API. You could still have inheritance on the parameters, but it would not make sense any longer for command classes to take arbitrary parameters - at the pro side of course this means that API users know which parameters are required exactly.
  • One command instance per context: If you need your commands to have things like visitBefore and visitAfter, whilst also reusing them with different parameters, you will be open to the problem of getting called with differing parameters. If the parameters should be the same on multiple method calls, you need to encapsulate them into the command such that they cannot be switched out for other parameters in-between the calls.
Related Topic