[PDF] - Chapter 15 Design P atterns Lik e most complex structures, PDF Document

SLIDE 1 Chapter 15 Design P atterns Lik e most complex structures, go

d

computer programs are

ften

formed b y imitating the structure

f
lder,

similar programs that ha v e already pro v en successful. The concept

f

a design p attern is an attempt to capture and formalize this pro cess

f

imitation. The basic idea is to c haracterize the features

f

a pro v en solution to a small problem, summarizing the essen tial elemen ts and

mitting

the unnecessary detail. A catalog

f

design patterns is a fascinating illustration

f

the m yriad w a ys that soft w are can b e structured so as to address dieren t problems. Later, patterns can giv e insigh t in to ho w to approac h new problems that are similar to those situations describ ed b y the pattern. This c hapter will in tro duce the idea

f

design patterns b y describing sev eral that are found in the Ja v a library . The terminology used in describing the patterns is adapted from the b

k

Design Patterns: Elements

f

R eusable Obje ct-Oriente d Softwar e, b y Eric h Gamma, Ric hard Helm, Ralph Johnson and John Vlissides [Gamma 1995 ]. This w as

ne
f

the rst b

ks

to describ e the concept

f

design patterns and pro vide a systematic cataloging

f

patterns. Man y more patterns than are describ ed here can b e found in this b

k,

as w ell as in the recen t literature

n

design patterns. The format used in describing eac h pattern is to rst c haracterize the problem the pattern is addressing. Then, the essen tial features

f

the solution are summarized. In some cases this is follo w ed b y a discussion that examines some

f

the con text for the problem,

r

con trasts alternativ e design p

ssibilities.

This is follo w ed b y a more detailed description

f

the pattern as it is manifest in the Ja v a Library . Finally , a sen tence

r

t w

summarizes

the situations where the pattern is applicable. 15.1 Adapter problem: Ho w do y

u

use an

b

ject that pro vides appropriate b eha vior but uses a dieren t in terface than is required in some situation? 259

SLIDE 2 260 CHAPTER 15. DESIGN P A TTERNS solution: Dene an adapter class that acts as an in termediary . The adapter do es little w

rk

itself, but merely translates commands from

ne

form in to the

ther.

discussion: In ternational tra v elers frequen tly

v

ercome the problem

f

diering electrical plug and v

ltage

standards b y using adapters for their appliances. These adapters allo w an electrical appliance that uses

ne

t yp e

f

plug to b e mo died so that it can b e used with a dieren t t yp e

f

plug. The soft w are equiv alen t is similar. An adapter is concerned mostly with c hanges in the in terface to an

b

ject, and less with the actual functionalit y b eing pro vided. Client Adapter W

rk

er example: An example

f

adapters in the Ja v a library are the \wrapp er" classes, Bo

lean,

Integer, and so

n.

These adapt a primitiv e t yp e (suc h as b

lean
r

int) so that they can b e used in situations where an Object is required. F

r

example, wrapp ers are necessary to store primitiv e v alues as elemen ts in a V ecto r. Another form

f

adapter is the class MouseAdapter used in the pin ball game describ ed in Chapter 7, as w ell as in the Solitare program presen ted in Chapter 9. Here the adapter reduces the in terface, b y implemen ting default b eha vior for metho ds that are unneeded in the curren t application. The clien t can therefore concen trate

n

the

ne

metho d that is used in the program. An adapter can b e used whenev er there is the need for a c hange in in terface, but no,

r

v ery little, additional b eha vior b ey

nd

that pro vided b y the w

rk

er. 15.2 Comp

sition

problem: Ho w do y

u

p ermit the creation

f

complex

b

jects using

nly

simple parts? solution: Pro vide a small collection

f

simple comp

nen

ts, but also allo w these comp

nen

ts to b e nested arbitrarily . The resulting comp

site
b

jects allo w individual

b

jects and comp

sitions
f
b

jects to b e treated uniformly . F requen tly , an in teresting feature

f

the comp

sition

pattern is the merging

f

the is-a relation with the has-a relation. example: A go

d

example

f

comp

sition

in the Ja v a library is the creation

f

design la y

uts

through the in teraction

f

Comp

nents

and Containers. There are

nly

v e simple t yp es

f

la y

uts

pro vided b y the standard library , and

f

these v e

nly

t w

,

b

rder

la y

uts

and grid la y

uts,

are commonly used. Eac h item in a la y

ut

is a Comp

nent.

Comp

sition
ccurs

b ecause Containers are also Comp

nents.

A con tainer

SLIDE 3 15.2. COMPOSITION 261 holds its

wn

la y

ut,

whic h is again

ne
f
nly

a few simple v arieties. Y et the con tainer is treated as a unit in the

riginal

la y

ut.

The structure

f

a comp

site
b

ject is

ften

describ ed in a tree-lik e format. Consider, for example, the la y

ut
f

the windo w sho wn in Figure 13.8

f

Chapter 13. A t the application lev el there are four elemen ts to the la y

ut.

These are a text area, a simple blank panel, and t w

panels

that hold comp

site
b

jects. One

f

these comp

site

panels holds three scroll bars, while the second is holding a grid

f

sixteen buttons.

P

P P P P

X

X X X X X

H

H H ::: Colo r = ( ( ( ( ( ( ( ( ( h h h h h h h h h

H

H H Colo r = [40,60,50] By nesting panels

ne

within another, arbitrarily complex la y

uts

can b e created. Another example

f

comp

sition

is the class SequenceInputStream, whic h is used to catenate t w

r

more input streams so that they app ear to b e a single input source (see Section 14.1.2). A SequenceInputStream is-a InputStream (meaning it extends the class InputStream). But a SequenceInputStream also has-a InputStream as part

f

its in ternal state. By com bining inheritance and comp

sition,

the class p ermits m ultiple sequences

f

input sources to b e treated as a single unit. This pattern is useful whenev er it is necessary to build complex structures

ut
f

a few simple elemen ts. Note that the merging

f

the is-a and has-a relations is c haracteristic

f

the wr app er pattern (Section 15.9), although wrapp ers can b e constructed that are not comp

sites.

SLIDE 4 262 CHAPTER 15. DESIGN P A TTERNS 15.3 Strategy problem: Ho w do y

u

allo w the algorithm that is used to solv e a particular problem to b e easily and dynamically c hanged b y the clien t? solution: Dene a family

f

algorithms with a similar in terface. Encapsulate eac h algorithm, and let the clien t select the algorithm to b e used in an y situation. discussion: If a complex algorithm is em b edded in a larger application, it ma y b e dicult to extract the algorithm and replace it with another, alternativ e v ersion. If sev eral alternativ e algorithms are included in the same

b

ject, b

th

the complexit y and the co de

f

the resulting

b

ject ma y b e increased unnecessarily . By separating problem and solution, it is easier for the clien t to select the solution (algorithm) appropriate for an y particular situation. example: An example

f

the use

f

the Str ate gy pattern is the creation

f

la y

ut

managers in the A WT. Rather than co ding in the comp

nen

t library the details

f

ho w items are laid

ut
n

the screen, these decisions are left to the la y

ut

manager. An in terface for La y

utManager

is dened, and v e standard la y

ut

managers are pro vided. The am bitious programmer is ev en allo w ed, should he

r

she c ho

se,

to dene a new

b

ject that satises the La y

utManager

in terface. Applic ation Container La y

utManager

GridLa y

ut

holds inherits implemen ts The activities

f

the design comp

nen

t (suc h as a P anel

r

a Windo w) is indep enden t

f

the particular la y

ut

manager that is b eing used. This b

th

simplies the con tainer comp

nen

t and p ermits a m uc h greater degree

f

exibilit y in the structure

f

the resulting la y

ut

than w

uld

b e p

ssible

if la y

ut

decisions w ere an in trinsic part

f

the con tainer. This pattern is useful whenev er it is necessary to pro vide a set

f

alternativ e solutions to a problem, and the algorithms used to address the problem can b e encapsulated with a simple in terface.

SLIDE 5 15.4. OBSER VER 263 15.4 Observ er problem: Ho w do y

u

allo w t w

r

more indep enden t and lo

sely

coupled

b

jects to c hange in sync hron y with eac h

ther?

solution: Main tain a list

f
b

jects that are tied,

r

dep enden t,

n

another

b

ject. When the target

b

ject c hanges, the dep enden ts are notied that they should up date them- selv es. discussion: It is easy to main tain tigh tly coupled

b

jects in sync hron y . F

r

example, if a new class is dened as a sub class

f

an existing paren t class, mo dications

f

the paren t that are made via metho d in v

cations

can b e monitored b y simply

v

erriding the metho ds. It is m uc h more dicult to k eep

b

jects in step with eac h

ther

when links are formed and brok en dynamically at run time,

r

when no

b

vious class relationship exists b et w een the separate elemen ts. example: There are t w

go
d

examples

f

the use

f

the

bserv

er pattern in the Ja v a library . The rst w e ha v e seen in man y earlier case studies, suc h as the cannon w

rld

examined in Chapter 6. Eac h

f

the user in terface comp

nen

ts that p ermits in teraction, suc h as buttons, scroll bars, and c hec k b

xes,

main tains a collection

f

listener

b

jects. This list is dynamic; listeners for an y comp

nen

t can b e easily added

r

remo v ed at run time. F urthermore, the structure

f

the listeners is not sp ecied, they are

nly

required to satisfy the necessary in terface. When the comp

nen

t c hanges state (the button is pressed, the slider mo v ed, the Chec kb

x

c hanged), eac h

f

the listeners is notied that a c hange has

ccurred.

It is up to the listener to decide what action should b e tak en as a result

f

the c hange. The idea b ehind listeners is also found in a more general facilit y that can b e used b y programmers for situations that do not in v

lv

e user in teraction. The library class Observable represen ts

b

jects that can b e \observ ed", the equiv alen t

f

the comp

nen

ts in the A WT mec hanism. Programmers can either sub class a new class from Observable,

r

simply create an Observable eld within a class. Other

b

jects can implemen t the Observer in terface. These corresp

nd

to \listener"

b

jects. An instance

f

Observer registers itself with the

b

ject b eing

bserv

ed. A t an y time, the Observable

b

ject can indicate that it has c hanged, b y in v

king

the message notifyObservers(). An

ptional

argumen t can b e passed along with this message. Eac h

bserv

er is passed the message up date(Observable, Object), where the rst argumen t is the Observable that has c hanged, and the second is the

ptional

argumen t pro vided b y the notication. The

bserv

er tak es whatev er action is necessary to bring the state in to sync hron y with the

bserv

ed

b

ject. The Observer pattern is applicable whenev er t w

r

more

b

jects m ust b e lo

sely

coupled, but m ust still main tain sync hronization in some asp ect

f

their b eha vior

r

state.

SLIDE 6 264 CHAPTER 15. DESIGN P A TTERNS 15.5 Flyw eigh t problem: Ho w can

ne

reduce the storage costs asso ciated with a large n um b er

f
b

jects that ha v e similar state? solution: Share state in common with similar

b

jects, thereb y reducing the storage required b y an y single

b

ject. example: With the exception

f

primitiv e v alues, all

b

jects in Ja v a are an instance

f

some class. With eac h class it is necessary to asso ciate certain information. Examples

f

information is the name

f

the class (a String), and the description

f

the in terface for the class. If this information w as duplicated in eac h

b

ject the memory costs w

uld

b e prohibitiv e. Instead, this information is dened

nce

b y an

b

ject

f

t yp e Class, and eac h instance

f

the class p

in

ts to this

b

ject. The

b

jects that share the information are kno wn as yweights, since their memory requiremen ts are reduced (often dramatically) b y mo ving part

f

their state to the shared v alue. The yw eigh t pattern can b e used whenev er there are a large n um b er

f
b

jects that share a signican t common in ternal state. 15.6 Abstract F actory problem: Ho w to pro vide a mec hanism for creating instances

f

families

f

b

jects without sp ecifying their concrete represen tations. solution: Pro vide a metho d that returns a new v alue that is c haracterized

nly

b y an in terface

r

paren t class, not b y the actual t yp e pro duced. discussion: There are sev eral instances where the v alue returned b y a function in the standard library is c haracterized b y either an abstract class

r

an in terface. Clearly the actual v alue b eing returned is a dieren t t yp e, but normally the clien t using the function is not concerned with the actual t yp e, but

nly

the b eha vior describ ed b y the c haracterizing attributes. example: Tw

examples
ut
f

the man y found in the Ja v a library will b e describ ed. Eac h

f

the collection classes V ecto r, Hashtable and Dictiona ry dene a metho d named elements() that is describ ed as returning a v alue

f

t yp e Enumeration. As Enumeration is

nly

an in terface, not a class, the v alue returned is clearly formed as an instance

f

some

ther

class. Almost alw a ys, the clien t has no in terest in the actual t yp e b eing yielded b y elements(), and is

nly

in terested in the b eha vior common to all v alues that satisfy the Enumeration in terface. A similar situation

ccurs

with the classes F

nt

and F

ntMetrics.

The class F

ntMetrics

is used to describ e the c haracteristics

f

a F

nt,

suc h as the heigh t and width

f

SLIDE 7 15.7. F A CTOR Y METHOD 265 c haracters, the distance c haracters extend ab

v

e

r

b elo w the baseline, and so

n.

A F

ntMetrics

is an abstract class,

ne

that cannot b e instanciated directly b y the programmer using the new command. Instead, a v alue

f

t yp e F

ntMetric

is returned b y a Graphics

b

ject in resp

nse

to the message getF

ntMetrics.

Clearly , the graphics

b

ject is returning a v alue deriv ed from a sub class

f

F

ntMetric,

but the particular v alue returned is normally

f

no concern to the clien t. A similar facilit y is used b y class Applet, whic h can return an AppletContext that describ es the curren t execution en vironmen t. The abstract factory pattern should b e used whenev er the t yp e

f

the actual v alue to b e created cannot b e predicted in adv ance, and therefore m ust b e determined dynamically . 15.7 F actory Metho d problem: Y

u

ha v e a metho d that returns a newly created

b

ject, but w an t sub classes to ha v e the abilit y to return dieren t t yp es

f
b

ject. solution: Allo w the sub class to

v

erride the creation metho d and return a dieren t t yp e

f
b

ject. discussion: This pattern is v ery similar to the abstract factory ,

nly

sp ecialized for the situation where new abstractions are formed using inheritance. example: The metho d clone() is a go

d

example

f

a factory metho d. This metho d returns a cop y

f

an

b

ject, pro vided the

b

ject supp

rts

the Cloneable in terface. The default metho d in class Object raises an exception, indicating that the cloneable in terface is not supp

rted.

Sub classes that wish to p ermit clones m ust

v

erride this metho d, and return a dieren t t yp e

f

v alue. Note that the v alue returned b y a factory metho d m ust b e the same for all classes. F

r

the Cloneable in terface this t yp e is Object. An y class that p ermits cloning will still return a v alue

f

t yp e Object in resp

nse

to the message clone(). This v alue m ust then b e cast to the appropriate t yp e. The factory metho d pattern is useful when there is a hierarc h y

f

abstractions formed using inheritance, and part

f

the b eha vior

f

these abstractions is the creation

f

new

b

jects. 15.8 Iterator problem: Ho w to pro vide a w a y to access elemen ts

f

an aggregate

b

ject sequen tially without exp

sing

the underlying represen tation.

SLIDE 8 266 CHAPTER 15. DESIGN P A TTERNS solution: Pro vide a mediator

b

ject for the sole purp

se
f

sequen tial access. This mediator can b e a w are

f

the represen tation

f

the aggregate, ho w ev er the clien t using the

b

ject need not b e a w are

f

these details. example: The Enumeration in terface for con tainer access actually addresses t w

related

problems. It pro vides a uniform means

f

accessing elemen ts from man y dieren t t yp es

f

con tainer, and it hides the details

f

the underlying con tainer represen tation. It is the second asp ect that mak es the Enumeration a go

d

example

f

the iterator pattern. Consider, for example, an en umeration that is generating elemen ts from a Hashtable. In ternally , a hash table is implemen ted as an arra y , eac h elemen t

f

the arra y b eing a list. V alues that hash in to the same lo cations are found

n

the same list. 6 5 4 3 2 1

3
25
1
72
9
5
12
23
31

The programmer who uses a hash table and wishes to iterate

v

er the v alues should not b e concerned with the represen tation, suc h as mo ving from

ne

list to the next when the elemen ts in

ne

hash lo cation ha v e b een exhausted. The hash table en umeration hides these diculties b ehind a simple in terface. The programmer sees

nly

the t w

metho

ds hasMo reElements() and nextElement(). With these, a lo

p

can b e written that do es not ev en hin t at the complex actions needed to access the underlying elemen ts. HashTable htab = new HashTable(); ... for (Enumeration e = htab.elements(); e.hasMoreElements () ; ) f Object val = e.nextElement(); ... g The fact that the metho d elements returns a v alue that is not directly an Enumeration, but is rather a v alue from another class that implemen ts the Enumeration in terface, is an example

f

the A bstr act F actory pattern (Section 15.6).

SLIDE 9 15.9. DECORA TOR (FIL TER OR WRAPPER) 267 The iterator pattern is useful whenev er an aggregate

b

ject is created that can hold an arbitrary n um b er

f

v alues, and it is necessary to pro vide access to v alues without exp

sing

the underlying represen tation. 15.9 Decorator (Filter

r

W rapp er) problem: Ho w can y

u

attac h additional resp

nsibilities

to an

b

ject dynamically? solution: By com bining the is-a and has-a relations, create an

b

ject that wraps around an existing v alue, adding new b eha vior without c hanging the in terface. discussion: Inheritance is

ne

tec hnique for pro viding new functionalit y to an existing abstraction. But inheritance is rather hea vy handed, and is

ften

not exible enough to accommo date situations that m ust dynamically c hange during the course

f

execution. A decorator wraps around an existing

b

ject, and satises the same requiremen ts (for example, is sub classed from the same paren t class

r

implemen ts the same in terface). The wrapp er delegates m uc h

f

the resp

nsibilit

y to the

riginal,

but

ccasionally

adds new functionalit y . Buered InputStream InputStream example: The class InputStream pro vides a w a y to read b ytes from an input device, suc h as a le. The class BueredInputStream is a sub class

f

InputStream, adding the abilit y to buer the input so that it can b e reset to an earlier p

in

t and v alues can b e reread t w

r

more times. F urthermore, a BueredInputStream can tak e an InputStream as argumen t in its constructor. Because a BueredInputStream b

th

is an InputStream and has an input stream as part

f

its data, it can b e easily wrapp ed around an existing input stream. Due to inheritance and substitutabilit y , the BueredInputStream can b e used where the

riginal

InputStream w as exp ected. Because it holds the

riginal

input stream, an y actions unrelated to the buering activities are simply passed

n

to the

riginal

stream.

SLIDE 10 268 CHAPTER 15. DESIGN P A TTERNS A decorator,

r

wrapp er class, is

ften

a exible alternativ e to the use

f

sub classing. F unctionalit y can b e added

r

remo v ed simply b y adding

r

deleting wrapp ers around an

b

ject. 15.10 Pro xy problem: Ho w do y

u

hide details suc h as transmission proto cols to remote

b

jects? solution: Pro vide a pro xy that acts as a surrogate

r

placeholder for another

b

ject. discussion: The idea

f

a pro xy is that

ne
b

ject is standing in place

f

another. The rst

b

ject receiv es requests for the second, and generally forw ards the requests to the second, after pro cessing them in some fashion. example: An example pro xy in the Ja v a Library is the RMI,

r

Remote Metho d In v

cation

system. The RMI is a mec hanism that can b e used to co

rdinate

Ja v a programs running

n

t w

r

more mac hines. Using the RMI, a pro xy

b

ject is created that runs

n

the same mac hine as the clien t. When the clien t in v

k

es a metho d

n

the pro xy , the pro xy transmits the metho d across the net w

rk

to the serv er

n

another mac hine. The serv er handles the request, then transmits the result bac k to the pro xy . The pro xy hands the result bac k to the clien t. In this fashion, the details

f

transmission

v

er the net w

rk

are handled b y the pro xy and the serv er, and are hidden from the clien t. Client Pro xy Server

Q

Q Q

15.11

Bridge problem: Ho w to decouple an abstraction from its implemen tation so that the latter can v ary indep enden tly . solution: Remo v e implemen tation details from the abstraction, placing them instead in an

b

ject that is held as a comp

nen

t in the abstraction. example: Most

f

the comp

nen

t classes in the A WT mak e use

f

the bridge pattern. F un- damen tally , this is b ecause the actions necessary to implemen t a graphical comp

nen

t v ary in great detail from

ne

platform to another. F

r

example, the actions needed to displa y a windo w are dieren t dep ending up

n

whether the underlying displa y is X-Windo ws/Motif, Windo ws-95,

r

the Macin tosh. Rather than placing platform sp ecic details in the class Windo w, instead eac h windo w main tains a comp

nen

t

f

SLIDE 11 15.12. CHAPTER SUMMAR Y 269 t yp e Windo wP eer. The in terface Windo wP eer has dieren t implemen tations, dep ending up

n

the platform

n

whic h the application is b eing executed. This separation allo ws a Ja v a program that dep ends

nly
n

the class Windo w to b e executed in an y en vironmen t for whic h there is a corresp

nding

p eer. The Bridge pattern is in man y w a ys similar to the Strategy pattern describ ed earlier. Dierences are that bridges are almost alw a ys hidden from the clien t (for example, the a v erage Ja v a programmer is generally una w are

f

the existence

f

the p eer classes), and are generally dictated b y en vironmen tal issues rather than reecting design decisions. 15.12 Chapter Summary An emerging new area

f

study in

b

ject-orien ted languages is the concept

f

design patterns. A design pattern captures the salien t c haracteristics

f

a solution to a commonly

bserv

ed problem, hiding details that are particular to an y

ne

situation. By examining design patterns, programmers learn ab

ut

tec hniques that ha v e pro v en to b e useful in previous problems, and are therefore lik ely to b e useful in new situations. F urther Reading The most imp

rtan

t reference for design patterns is the b

k
f

the same name [Gamma 1995 ], b y Gamma, Helm, Johnson and Vlissides (commonly kno wn as the Gang

f

F

ur,
r

GOF). Another recen t b

k
n

patterns is b y Ric hardndexGabriel, Ric hard Gabriel [Gabriel 1996 ]. Study Questions 1. In what w a ys is an adapter similar to a pro xy? In what w a ys are they dieren t? 2. In what w a y is the comp

sition

design pattern similar to the idea

f

comp

sition

examined in Chapter 10? 3. In what w a ys is a strategy similar to a bridge? In what w a ys are they dieren t? 4. In what w a ys is an iterator similar to an adapter? Exercises 1. What design pattern is exhibited b y the class PrintStream (see Section 14.2)? Explain y

ur

answ er.