Command

1. 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 • 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() { /* CHALLENGE! */ }); } 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 • 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?