1. Doug Jeffries CS490 Design Patterns May 1, 2003
Command
Doug Jeffries
CS490 Design Patterns
May 1, 2003

2. Overview What is Command? UML for Command interface Examples
Challenge problems

3. What is Command? GOF definition Object-oriented version of callbacks
Encapsulate commands in objects so that you can control their selection, sequencing, queue them, undo them and otherwise manipulate them.
Object-oriented version of callbacks
Callbacks are functions registered to be called later

4. What is Command?
Keeps the invoker of a function from needing a reference to the receiver which implements the action.
Invoker often does not care
Simply wants to issue abstract command
Sometimes called Transaction or Action

5. UML

6. Example Restaurant Customer is the Invoker Waiter is the Command
Taking the order is the execution of command
Staff are the Receiver
Cook prepares the ordered dish
Janitor cleans floor after cook spills your food on the floor
Waiter delivers it, and probably your bill
Paying your bill is another command you will execute
Cashier accepts payment
Busboy clears the table when you finish
Valet brings your car around

7. In the Wild
Where have you seen this pattern?

8. In the Wild Waiter example javax.swing.Action
JButton may be the Invoker
no knowledge of Receiver
Action is the Command
provides actionPerformed()
Action delegates to some Receiver

9. Vehicle Example

10. Metsker’s Challenge 24.1
The mechanics of Java menus make it easy to apply the COMMAND pattern, but they do not require that you organize your code as commands.
In fact, it is common to develop an application in which a single object listens to all the events in a GUI.
What pattern does that follow?

11. Metsker’s Solution 24.1
Java Swing applications commonly apply the MEDIATOR pattern, registering a single object to receive all GUI events. This object mediates the interaction of the components and translates user input into commands for business domain objects.

12. Metsker’s Challenge 24.2
Fill in the code for the anonymous subclasses of ActionListener, overriding actionPerformed(), noting that this method expects an ActionEvent argument.

13. Metsker’s Challenge 24.2 protected JMenu fileMenu() {
if(fileMenu == null) {
fileMenu = new JMenu("File");
Font f = SwingFacade.getStandardFont();
fileMenu.setFont(f);
JMenuItem save = new JMenuItem("Save");
save.setFont(f);
fileMenu.add(save);
save.addActionListener(new ActionListener()
{ /* CHALLENGE! */ });
JMenuItem load = new JMenuItem("Load");
load.setFont(f);
fileMenu.add(load);
load.addActionListener(new ActionListener() }
return fileMenu;

14. Metsker’s Solution 24.2 load.addActionListener( new ActionListener() {
public void actionPerformed(ActionEvent e)
save(); // or load(); }
});

15. Challenge 1
Compare Command to Strategy

16. Solution 1 Similarities Differences
Both provide ways for actions to be performed abstractly, without having to care about the details of the implementer.
Differences
Strategy requires the invoker of the action to have a reference to the implementer

17. Challenge 2
How might Command make it easier to support an undo operation?

18. Solution 2
Your Command interface could be extended to have an unexecute() method, and state could be stored by the command object itself.
Store previously executed commands in a history stack.

19. Challenge 3
Could logging functionality be added in a similar way as undo was in the previous challenge?

20. Solution 3 Yes. Simply add load() and save() to the Command interface.
State can be restored by reloading the logged commands and executing them in the proper order.

21. Comments?