These four classes retain the look and feel of their underlying operating system. For all other graphical elements, however, even their appearance can be changed. Swing components delegate the task of representing themselves onscreen to an associated UI class, which can be changed. The upshot of this is that a Swing application can look like a Solaris GUI even if it is run on a Windows platform. This capability is called pluggable look and feel, or PLaF for short.

General Pattern Use

Observer (see page 94): As complex architectures, AWT and Swing both use their share of design patterns. The most often used pattern is Observer, of course. The Observer pattern allows for a flexible way of communicating between objects. Both architectures use the Observer pattern to manage event handling. In both cases, the graphical components represent the Observable class, and programmers write the Observer.

Composite and Chain of Responsibility (see page 157 and page 42): Since both AWT and Swing graphical elements are based on the AWT Container and Component classes, the APIs allow for GUI tree structures to be created. This suggests Composite and Chain of Responsibility patterns in the API.

The Composite pattern is found in several Container-Component methods, although it occurs less frequently than you might think. The list methods, used to print out the graphical components to a stream, use the Composite pattern, as does the method readObject (used to serialize object state to a stream). Several methods fall short of true Composite behavior because they call different methods for Containers and Components rather than using a single method defined in the Component class and overridden in the other classes.

Chain of Responsibility is demonstrated in a number of methods. Recall that Chain of Responsibility involves delegation of behavior,

often to the parent in a tree structure. Most Component methods that involve getting standard component properties use this pattern. Examples are getForeground, getBackground, getCursor, and getLocale.

Pattern Use in AWT

Singleton (see page 34): The Toolkit class provides an interesting example of the Singleton design pattern. Toolkit uses Singleton to produce what is called a default Toolkit and to ensure that this single default Toolkit is globally available. This Toolkit is obtained by a call to the static getDefault-Toolkit method, and is normally used by developers to obtain a Toolkit if they need to do things like create a print job. Since Toolkit is an abstract class, redefined for a specific operating system, it is entirely possible that concrete implementations of Toolkit have constructors and allow other instances of Toolkit to be created within the system—in fact, Sun's implementation for Windows does. The “default” toolkit, however, remains the same.

Bridge (see page 150): You could potentially say that the AWT peer architecture is similar to the Bridge pattern, which separates a component into two hierarchies: an abstraction and an implementation hierarchy. The AWT components represent the Abstraction for the Bridge, the peers are their Implementor counterparts, and a specific peer for an operating system is a ConcreteImplementor. There are two slight deviations from the classic Bridge pattern:

Many of the component classes actually perform some behavior, rather than delegating to their Implementor, the peer.

The component classes are not refined. This means that there is not really a distinction between Abstraction and

RefinedAbstraction as there is in the classic Bridge pattern.

Prototype (see page 28): AWT also has a number of Prototype implementors that have some way of making a copy of an instance. Predictably, these classes represent potentially reusable resources in the AWT architecture:

Insets, GridBagConstraints, Area, and PageFormat.

Pattern Use in Swing

MVC (see page 208): Probably the best-documented design pattern in the Swing API is the Model-View-Controller (MVC) .

Almost all of the complex GUI elements in Swing use the component-level form of the MVC pattern. There are a number of excellent reasons for using the pattern, including the following:

It's possible to use a single underlying model to drive multiple view-controller pairs.

190

It's much easier to customize a component using this pattern, since programmers frequently only have to modify select parts of the component functionality.

Swing implements the MVC pattern very consistently in the API. Model functionality is represented by interfaces, as is controller behavior. The View elements are managed through a UI class hierarchy, which has its foundation in the javax.swing.plaf package. The basic view behavior is set out as a series of abstract classes, which can subsequently be refined to provide a different look and feel.

As an example, consider the JButton, the class which is used to represent a simple push button. It is associated with a ButtonModel implementor for the model, a ButtonUI for its view, and possibly one or more event handlers for its controller.

Prototype (see page 28): Like AWT, Swing also has a number of utility classes that can be cloned, and which therefore implement the Prototype design pattern: AbstractAction, SimpleAttributeSet, HTMLEditorKit,

DefaultTreeSelectionModel.

TEAM FLY PRESENTS

191