|
|
The Command pattern benefits both the client and the server
Author: David Geary
From: javaworld.com
Date: June 28, 2002
Summary
The Command pattern lets an application framework make requests of application-specific objects, without the framework knowing the objects' exact type or the application-specific behavior they implement. In his latest Java Design Patterns column, David Geary explores how to use the Command pattern both in client-side Java to attach application-specific behavior to Swing menu items and in server-side Java to implement application-specific behavior with the Apache Struts application framework. (2,700 words; June 28, 2002)
If you've been developing software long enough, you might recall a time before object-oriented (OO) development went mainstream when software development proved much more difficult than it is today. In those days, developers wrote software using archaic function libraries to develop applications entirely from scratch, using low-level functions from those libraries to develop software systems. For the fruits of their labors, developers produced software such as Microsoft Windows 3.1, which ever since has been known as the poster boy for clunky software that crashed soon after your last reboot.
Today, of course, things have improved considerably. Instead of Windows 3.1, we now have Windows XP, a vast improvement over its predecessors, and other software marvels, such as the amazing Mac OS X. Many factors contributed to the increase of software productivity and reliability over the years, but the overriding factor has been the widespread adoption of OO design and development, which turned the paradigm of developing software from scratch with function libraries completely inside-out. With OO design, developers employ application frameworks that provide the majority of an application's code and implement applications by plugging reusable components into those frameworks.
In the early days, when application frameworks first appeared, developers faced a major hurdle. Application frameworks must issue requests to application-specific objects without knowing anything about those objects or the operations they perform. For example, the Swing application framework issues requests to objects when menu items are activated or buttons are pressed. Swing can't implement those requests because they are application-specific. So how does an application framework like Swing issue requests to objects without knowing anything about the requested operation or the objects themselves? The answer: the Command design pattern.
In this article, I discuss the Command pattern, sometimes known as the Action pattern, from two different perspectives. First, I show how the Command pattern works in client-side Java with Swing's implementation of the Command pattern for menu items. Second, I discuss how the Command pattern works in server-side Java to parameterize HTTP requests with the Apache Struts JSP (JavaServer Pages) framework. Along the way, you will learn a bit about Swing, Struts, and the newest kid on the server-side Java block, the JSP Standard Tag Library (JSTL).
Note: You can download this article's example source code from Resources.
The Command pattern
In Design Patterns, the authors define the Command pattern as:
[i]Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.[/i]
By implementing commands as objects, the Command pattern lets application frameworks invoke methods of application-specific commands. Figure 1 shows a Command pattern class diagram.
[i]Figure 1. Command pattern class diagram[/i]
In Figure 1, the Invoker class represents an object in an application framework, such as a button or menu item. The Invoker maintains an association with a command through a reference to an object that implements a Command interface, which defines an execute() method. Concrete command classes implement that interface, typically by using an object known as a receiver—application-specific objects that carry out the request. Figure 2 shows a Command pattern sequence diagram.
[i]Figure 2. Command pattern sequence diagram [/i]
At runtime, the Invoker calls the Command's execute() method, and the Command invokes a Receiver's method—modeled here as an action() method—that carries out the request.
Swing actions
Almost all OO application frameworks implement the Command pattern, and Swing is no different. This section illustrates how Swing uses the Command pattern to perform application-specific functionality tied to Swing buttons serving as the building blocks for other components, such as menu items or toolbar buttons.
Swing implements the Command pattern with action objects. Whenever you select a Swing menu item or activate a Swing button, those action objects issue a request to an application-specific action. Figure 3 shows a class diagram for Swing actions and how they relate to buttons and menus.
[i]Figure 3. Swing actions class diagram. Click on thumbnail to view full-size image.[/i]
Buttons, defined by the AbstractButton class, serve as the Swing workhorses. For simplicity's sake, Figure 3's class diagram does not show all of the classes that ultimately extend AbstractButton because there are many AbstractButton ancestor classes. (Note: Figure 3 also omits most of the AbstractButton methods.) Swing buttons, radio buttons, toggle buttons, check boxes, menus, menu items, check-box menu items, and radio-button menu items are all AbstractButton class extensions. That class maintains a reference to an action defined by the Action interface. You can set or get that reference with the AbstractAction setAction() and getAction() methods, respectively.
Whenever one of the aforementioned Swing components activates, it calls its action's actionPerformed() method, which implements some application-specific functionality. As a convenience, Swing's AbstractAction class eases the implemention of application-specific actions. Let's see how.
Figure 4 shows a Swing application with a single menu featuring two menu items: "show dialog" and "exit." When you activate the "show dialog" menu item, as depicted in Figure 4's top picture, an application-specific action displays the dialog box shown in Figure 4's bottom picture. When you activate the "exit" menu item, another application-specific action terminates the application.
[i]Figure 4. Swing actions in action[/i]
The application shown in Figure 4 is listed in Example 1 following. |
|
