Sandy and Arthur work at different branches of a large company several thousand miles apart. Sandy began writing a program to learn how to use the Swing classes and eventually integrated the program into her work assignment. She started by using a JTabbedPane component and a JTree component. Then she added the Swing JToolBar component, as well as several toolbar buttons to control the program commands.

As she began to experiment with displaying various kinds of data, she realized that she could use a JTextField to enter a search query and the JTree to display a list of suggested query refinement terms, as shown in Figure 34.1.

Figure 34.1. A display with a number of interacting elements.

Then she realized that she could insert a JList into another of the tabbed panes and use it to display titles of documents. Figure 34.2 shows the summary of the selected document.

Figure 34.2. Clicking on a document title displays the summary in the lower box.

Then, just as she got these functions working and was about to leave on a trip to the West coast to work with Arthur, she obtained some code from Dick that allowed her to annotate displayed documents using the GlassPane methods of the JFrame component. This is shown in Figure 34.3.

Working under cramped conditions on the flight, she integrated that code into the working program and showed it to Arthur on her arrival. He was impressed with the program so far. After working with Sandy for a day or so and integrating her server technology, he was even more pleased with their joint work. But Sandy was less pleased because she knew that they had just hastily written a tangle of interacting classes that was nearly impossible to maintain or understand. When she expressed her concerns to Arthur, he took a familiar textbook off the shelf.

"Here's a copy of Design Patterns, " he said. "I think you'll find some good ideas on how to modify our program to be less confusing."

Sandy took the book back to her motel room and began thumbing through the catalog of patterns. By the next day, she had the beginnings of some ideas.

"Look," she said, “we can look at this program as a set of data objects or as a set of visual objects. Either way, we have to minimize the amount that each object needs to know about the others, so we can modify an object without changing any others. If we consider the applet as a set of data interaction objects, then the toolbar buttons call on data and change display elements.

And every object interacts with two or three others! What a mess!”

"Well," said Arthur, “maybe we should think about the display elements as the important objects to isolate. Then we have the following:

And they all communicate with the data server! It's still a tangle!”

"Let's think about those design patterns I've been reading about. It's easy to see that the toolbar buttons should communicate using the Command pattern so that we can undo that long if statement in the actionPerformed method. In fact, we could make the two JToolBars the ActionListeners for the buttons that they contain."

"But," said Arthur, "I don't see how that helps us keep these objects untangled. Every button needs to call methods in different objects. The Search button alone has to communicate with the text field, the search engine server, and the lists in the JTabbedPane. And the Clear button has to clear everything! Then every Command object would be calling methods in three or five other objects. That's no good. Maybe we could insert some other object that could manage this more sensibly."

"Let's see," Sandy said. “That sounds kind of familiar. You know, that Mediator pattern does just that. It says here that it

That's just what we need. Let's look at the interactions now.”

They drew them on the board together.

"See," said Sandy, "the Mediator gets the commands from all of the buttons. It decides which objects need to know about them. Then, if we change the classes, we have to change only the Mediator."

"But what about the server?" asked Arthur. "The search engine takes some time to return all of the information. How can we refresh the display later without hanging the system?"

"That sounds like an Observer pattern to me," said Sandy. "We spin off the search request in a different thread and notify the Observer when the result comes back. Then the Observer can tell the Mediator that it is time to change the display objects. That's pretty good. We've gotten most of the tangles out of this rat's nest."

"And, you know," said Arthur, "we can simplify the code that loads that display list box using an Adapter pattern. And not only that, the ListModel already is implementing the AbstractListModel. Isn't that an example of the Template pattern? Patterns aren't so hard. This is going to make this project so much easier."

To read more about Sandy's project, review the papers by Cooper and Byrd [1997, 1998] and Neff and Cooper [1999] in the bibliography.