Command Pattern

CSC-430

Phillip Wright

The Command Pattern

Encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations

AKA: Action, Transaction

Command Pattern

public interface Command{
  public void execute();
}

final Projector projector = new Projector();
final Command projectorOn = new Command(){
  public void execute(){
    projector.turnOn();
    projector.setInput();
  }
}

final Button button = new Button(projectorOn);

Command Pattern II

Doesn’t this look familiar?

Command Pattern III

It kind of feels like the strategy pattern, because we’re passing in an algorithm that should be used by the button at runtime.

It also kind of feels like the adapter pattern, because we are adapting the interface of the projector to the Command interface.

Lambdas Again

So, are we doing OO for the sake of OO again? To begin with, we could write:

final Projector projector = new Projector();
final Button button = new Button(
  ()->{
    projector.turnOn();
    projector.setInput();
  });

Lambdas Again II

If we write our methods so that they return the object they are called on to simulate function composition, we get:

final Projector projector = new Projector();
final Button button = 
  new Button(()->projector.turnOn().setInput());

Question

Could we instead write:

final Projector projector = new Projector();
final Button button = 
  new Button(projector.turnOn().setInput());

Lazy Execution

We can’t make this change, because the point of the Command pattern is to decouple the object that performs a computation from the object that invokes that computation.

In other words, we are deferring the execution of the computation until it is needed.

Command Pattern IV

We can extend our commands to do some other interesting things. For instance, we can provide an inverse operation to provide support for undoing operations.

public interface Command{
  public void execute();
  public void undo();
}

Command Pattern V

final Button button = new Button(new Command(){
  private Input prevInput = null; // LOLOLOLOLOL
  public void execute(){
    prevInput=projector.getInput();
    projector.nextInput();
  }

  public void undo(){
    if(prevInput!=null){
      projector.setInput(prevInput);
    }
  }
});

Macros

The logic we put in our commands is also free to contain references to other commands, which means we could build macros!

public class MacroCommand implements Command{
  private final List<Command> commands;
  public MacroCommand(final List<Command> commands){
    this.commands=commands;
  }
  
  public void execute(){
    for(final Command cmd : commands){
      cmd.execute();
    }
  }
}

Macros II

final List<Command> commands = new ArrayList<>;
commands.add(new Command(){/*turn on projector*/});
commands.add(new Command(){/*set projector to hdmi*/});
commands.add(new Command(){/*turn on bluray player*/});
commands.add(new Command(){/*turn off lights*/});
final Command watchMovie = new MacroCommand(commands);

Command Pattern VI

• Object oriented replacement for callbacks
• Decouples the invoking object from the operation implementing object
• Commands are first class objects
  • We can queue them
  • We can create transactions
  • Can be used for event logging
  • …and more

When To Use

• You need to parameterize objects with an action to perform
• You need to specify, queue, and execute requests at different time
• You need to support undo, redo, etc.
• You need to support logging changes to recreate state in case of failure
• You need to use high level operations which consist of several primitive operations

Warning

Undo operations can quickly get out of hand, as you may need to store a lot of state if you support multiple levels of undo!