1. Summary prepared by Kirk Scott
Chapter 24 Command
Summary prepared by Kirk Scott

3. Bronze cast of the furcula of "Sue" the Tyrannosaurus, Field Museum

4. Design Patterns in Java Chapter 24 Command
Summary prepared by Kirk Scott

5. The Introduction Before the Introduction
The ordinary way for a client to cause a method to execute is to call it (on an object), in-line
There may be other times when the client can’t specify exactly when or where a particular method should be called, but would like to be able to pass the method to another piece of code which will call it when needed

6. This can be accomplished by writing a class which contains the desired method
Then at run time an instance of that class can be constructed
That object can have the method called on it
Passing the method can be accomplished by passing the object to another piece of code as an explicit parameter

7. Book definition:
The intent of the Command pattern is to encapsulate a request in an object.
Comment mode on:
Notice that this is what has always happened when writing a class definition and putting a public method in it.
You learned to pass objects as parameters a long time ago, and within receiving code it is possible to call methods on the parameters

8. A Classic Example: Menu Commands
This part of the overheads is presented using Java swing code examples
This is retained (for the time being) because the code is straightforward
It is based on the idea of attaching listeners to objects without any confusion about XML files or layouts that would come from Android
In other words, it is simple “programmatic” code

9. Menus and listeners work together using the Command design pattern
They illustrate the idea that the application writer can’t predict in advance when a user will select a menu item, but can write the code to deal with it when it happens

10. In schematic form, these are the steps in creating a menu in code:
JMenuBar myMenuBar = new JMenuBar();
JMenu myMenu = new JMenu(“File”);
myMenuBar.add(myMenu);

11. These steps are followed by the steps for adding items to the menu:
JMenuItem myExitMenuItem = new JMenuItem(“Exit”);
ExitListener myExitListener = new ExitListener();
myExitMenuItem.addActionListener(myExitListener);
myMenu.add(myExitMenuItem);

12. This is what its code looks like:
The ExitListener is implemented as an inner class of the frame which has the menu
This is what its code looks like:
private class ExitListener implements ActionListener {
public void actionPerformed(ActionEvent event)
System.exit(0); }

13. The ExitListener class has an actionPerformed() method in it
The actionPerformed() method is executed when the Exit item is clicked in the menu
In the constructor for the frame, where the menu is being created, it is impossible to predict when the Exit item will be clicked
In other words, it is impossible to predict when the actionPerformed() method will be called

14. It is this line of code that illustrates the Command design pattern
That’s all right
The following line of code shows how actionPerformed() is linked to the menu item
It is this line of code that illustrates the Command design pattern
myExitMenuItem.addActionListener(myExitListener);
The object myExitListener is passed to myExitItem as an explicit parameter in the call to addActionListener

15. The actionPerformed() method can be called on myExitItem in the future in response to a mouse click on myExitItem
This is mildly cryptic because programmer written code does not contain the call myExitListener.actionPerformed()
The actual call is made by the system through Java’s event handling mechanism
Even so, the Command design pattern is evident in the way the item and the listener are linked

16. The book notes that once again, polymorphism is at work in the way menus function
Each menu item can have a different listener which takes different actions
Each listener has a method with the same name, actionPerformed()

17. Which action is performed depends on which kind of listener the system calls actionPerformed() on
The system only needs to know that in each case, actionPerformed() should be called, and polymorphism makes sure that the right action is taken for each different kind of listener

18. The system calls the actionPerformed() method on the listener object
The system has access to the objects that are declared as listeners in a program

19. Menu Commands and the Mediator Pattern
Challenge 24.1
The mechanics of Java menus make it easy to apply the Command pattern but 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?

20. Comment mode on:
This may be an interesting question, but the authors are spinning out into space now
This question is unrelated to understanding the design pattern in question.

21. Solution 24.1
Many Java Swing applications 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.

22. Notice that the approach just described could be a mess to implement for menus and it could be equally messy for other situations
If you had a single listener for all menu items, the contents of the actionPerformed() method would degenerate into a series of if/else statements

23. These if/elses would have to determine which item had been clicked
Their bodies would consist of blocks of code implementing the appropriate actions
Notice how this is exactly the opposite of having many different listeners and relying on polymorphism and dynamic binding to take care of which action to take

24. The Command and Strategy Patterns
If you think back to the Strategy design pattern, for example, that was the kind of mess you were hoping to avoid
Instead of having if/else code, the solution was to have different classes for each strategy (in this case, each menu item)
Each class would have a method with the same name but containing the implementation of a different strategy (in this case, a different action to be performed)

25. In other words, the handling of menus in Java exhibits the characteristics of two design patterns
The fact that there are different listener classes, each with an actionPerformed() method illustrates the Strategy design pattern
The fact that listeners are added to items so that their actionPerformed() method can be called in the future when needed illustrates the Command design pattern

26. Recall also, that with the Strategy design pattern you ended up with lots of little classes, each containing just a single method, and which you only needed one instance of
The same thing happens with (standard) menus
There is a different kind of listener for each menu item
Each listener just contains an implementation of actionPerformed()
Only one instance of each listener is needed

27. Challenge 24.1
Fill in the code for the anonymous subclasses of ActionListener, overriding the actionPerformed() method. Note that this method expects an ActionEvent argument.

28. Solution 24.2
Your code should look something like this:
Comment mode on:
In the book, the solution code is followed by some additional remarks
Instead of putting them at the end, they are given up front here, followed by a comment on them, followed by the code

29. Book’s remarks on the solution code:
Although the actionPerformed() method requires an ActionEvent argument, you can safely ignore it.
The menus() method registers a single instance of an anonymous class with the Save menu item and a single instance of another anonymous class with the Load menu item.
When these methods are called, there is no doubt about the source of the event.

30. Comment mode on:
There are two things to say about this:
First of all, the book’s statement forewarns us that the creation of the menu in the solution code occurs in a separate method in the application, named menus()

31. Secondly, there is nothing new in the remarks about the ActionEvent parameter
We have generally ignored it when writing menu listeners
There has generally been no need to do anything with the event parameter in a listener

32. The book’s solution code is given on the following overheads
Keep in mind the purpose of the challenge and the code shown
It is to illustrate how menu listeners (in this case, anonymous ones) make use of the Command design pattern

33. public class Visualization2 extends Visualization {
public static void main(String[] args) {
Visualization2 panel = new Visualization2(UI.NORMAL);
JFrame frame = SwingFacade.launch(panel, "Operational Model");
frame.setJMenuBar(panel.menus());
frame.setVisible(true); }
public Visualization2(UI ui)
super(ui);

34. public JMenuBar menus(){
JMenuBar menuBar = new JMenuBar();
JMenu menu = new JMenu("File");
menuBar.add(menu);
JMenuItem menuItem = new JMenuItem("Save As...");
menuItem.addActionListener(new ActionListener()
public void actionPerformed(ActionEvent e)
save(); }
});
menu.add(menuItem);
menuItem = new JMenuItem("Restore From...");
restore();
return menuBar;

35. public void save() {
try
mediator.save(this); }
catch (Exception ex)
System.out.println("Failed save: " + ex.getMessage());
public void restore()
mediator.restore(this);
System.out.println("Failed restore: " + ex.getMessage());

36. Using Command to Supply a Service
In the previous example, half the work was done by the Java API
All that was necessary was to plug a command into an existing context
In other words, the addActionListener() machinery is provided by the API
It is also possible for a programmer to provide both the context and the command

37. The Next Example
The next example shows how to time how long it takes to execute some method, methodA()
There will be a timing method, methodB(), that takes as its input parameter an object which can have methodA() called on it
Inside methodB() the call to methodA() on the input parameter will be sandwiched between timing code

38. Setting up the Command to be Passed
Let there be an abstract class named Command which includes this abstract method declaration:
public abstract void execute();
A concrete command class would extend Command and implement execute()
The abstract method, execute(), defines the interface for using a command object

39. Setting up the Code that will Receive the Command
In addition to a concrete command class, the example includes a class named CommandTimer
This class contains a static method named time()
The time() method takes as an input parameter an instance of a command class
execute() is called on that command class object in the body of the time() method

40. Calls to methods that make it possible to keep track of the passage of time can be placed before and after the call to execute() in the time() method
Code for the CommandTimer class and its time() method are given on the next overhead
Keep in mind that the method is static.

41. public class CommandTimer{
public static long time(Command command)
long t1 = System.currentTimeMillis();
command.execute();
long t2 = System.currentTimeMillis();
return t2 – t1; }

42. The book next presents code to test the setup, with the call that causes the execution missing
The code with the missing step is not reproduced here because it is immediately followed by a challenge to fill in the missing line of code
It’s easier to just go directly to the complete example with all of the pieces included

43. The authors are trying to illustrate the use of a JUnit test framework
This is mentioned in Appendix C, on the source code, and also at various points in the text
You don’t have to worry about it
It just adds a little stuff at the end of the example code which you can ignore
They also use the anonymous class syntax when creating the command

44. Challenge 24.3
Complete the assignment statement that sets the value for actual in such a way that the doze command is timed.

45. Solution 24.3
The testSleep() method passes the doze command to the time() utility method.
Comment mode on:
The code creates an instance of Command, named doze
It then calls the static time() method, passing doze as a parameter
See the code on the next overhead.

46. public class TestCommandTimer extends TestCase{
public void testSleep()
Command doze = new Command()
public void execute()
try
Thread.sleep( Math.round(10 * Math.random())); }
catch (InterruptedException ignored) };
long actual = CommandTimer.time(doze);
long expected = 2000;
long delta = 5;
assertTrue("Should be " + expected + " +/- " + delta + " ms",
expected - delta <= actual
&& actual <= expected + delta);

47. The point of the foregoing example code was that it created an object of the Command class named doze
This object contained an execute() method that caused it to sleep for a random amount of time
The line of code shown below made use of the command machinery given previously to time how long it takes for doze.execute() to run
long actual = CommandTimer.time(doze);

48. Command Hooks
This section builds on material that was presented in the chapter on the Template Method
You may recall that in that chapter I restricted myself to the discussion of sorting as implemented in the Java API
I did not pursue the other examples
Therefore, it is not possible to pursue this example in this chapter
You are not responsible for it

49. Command in Relation to Other Patterns
The book states that command is similar to a pattern in which a client knows when an action is required but doesn’t know exactly which operation to call.
This may be true, but this is not exactly what the examples in this chapter have illustrated.

50. In the menu example, there was uncertainty about the timing of the call (sometime in the future) but which actionPerformed() method was linked to which item was well defined
In the timing example there was also no doubt about what to do—just a need to encase a call to it in other predefined blocks of code

51. Challenge 24.5
Which pattern addresses the situation in which a client knows when to create an object but doesn’t know which class to instantiate?

52. Comment mode on:
This challenge introduces yet another slight difference between the thing they’re talking about and the examples they’re giving:
Now we’re talking about the creation of an object.
Since we don’t know what to create, this must mean calling a “creational” method rather than calling a constructor.

53. Solution 24.5
In Factory Method, a client knows when to create a new object but not what kind of object to create.
Factory Method moves object creation to a method that isolates a client from knowing which class to instantiate.
This principle also occurs in Abstract Factory.

54. Comment mode on:
The foregoing observation is certainly true
After a while all of the patterns begin to look similar
In particular, you observe a “meta pattern” that there are some patterns that work with vanilla methods, and there are other analogous patterns that work with methods that create objects

55. An Example using Command with other Patterns
The Command design pattern can be used with other design patterns
The book gives code showing Command and Mediator being used together in a MVC design for their Visualization program
MVC hasn’t been covered yet.
Still, the example can be covered as a combination of mediator and command.

56. In this example the mediator class is responsible for returning instances of different kinds of listeners, as needed, for the buttons created in the application
The example code which will be given next shows part of the controller portion of an MVC design
It’s the creation of a graphical button in a visualization with a listener attached to it

57. The code contains a call like this: mediator.undoAction()
This doesn’t “undo an action” on the mediator
It returns an “undo listener” which the mediator is responsible for keeping track of

58. The listener returned is used as an explicit parameter in this call: undoButton.addActionListener()
This is the point where the command pattern is in evidence
Attaching a listener to a button is analogous to attaching a listener to a menu item
This example is analogous to the first example in the unit except that the listener comes from the mediator

59. protected JButton undoButton(){
if (undoButton == null)
undoButton = ui.createButtonCancel();
undoButton.setText("Undo");
undoButton.setEnabled(false);
undoButton.addActionListener(mediator.undoAction()); }
return undoButton;

60. Other Code for this Example
If you go to the book’s Web site you can find the code for the VisMediator class
Details of that class are not of interest at the moment
All you need to know is that it contains implementations of methods like undoAction(), which return listeners
Methods of this kind with different names return different kinds of listeners

61. actionPerformed() is the Command that is Packaged in a Listener
When the listener is added to the button, the command that is being packaged up in the object is actionPerformed()
Different versions of actionPerformed() contain calls to methods (commands) that do different things
These commands are ultimately what is triggered by this use of the Command design pattern

62. UML for the Pattern
A progression of UML diagrams for the pattern is shown on the following overheads
The first diagram shows the simple roots of the pattern
The second shows the direct use of a command
The third shows that in reality, a given context could make similar use of many different commands

66. Lasater’s UML for the Pattern
Lasater’s diagram attempts to show that a generic execute() command is really just a wrapper for a call to some action that is significant within the problem domain or context.

68. Summary
The Command design pattern makes it possible to encapsulate a request for service in an object
In other words, calls to methods can be managed by passing around objects which can receive the calls
The actual calls can be made at the time needed or when necessary conditions have been met

69. The Command design pattern is illustrated by the way menus are constructed in Java
The listener for an item is an object which can have the actionPerformed() method called on it
The listener is passed to the item as an explicit parameter in a method call
actionPerformed() is actually executed only at the time that the item in the menu is selected

70. The second example illustrated how the Command design pattern can be used to embed a call between blocks of code
The third example in the book was not pursued, and you are not responsible for it
That example happened to illustrate that the command pattern can be used to accomplish things that the Template Method design pattern can also be used to accomplish

71. The idea of passing an object as a parameter and then calling methods on the object in the body of the receiving method is very basic
You have written code that works this way many times without thinking about it or trying to classify it as some sort of pattern

72. It takes on the meaning of a design pattern depending on the context in which it’s used
In practice, the command pattern doesn’t necessarily appear in isolation
It may appear in a more complex design in combination with the Mediator, Memento, and other design patterns

73. The End