Java Reference
In-Depth Information
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.
