Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Take command of your software

The Command pattern benefits both the client and the server

By David Geary, JavaWorld.com, 06/28/02

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:

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

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.