Patterns go f

Gang-of-Four Design Patterns

OOA&D - v3.2 - English

Object-Oriented Analysis and Design
About the GoF Design Patterns
N

Gang-of-Four: Gamma, Helm, Johnson, & Vlissides.
Intermediate-level design patterns.

Large Architectural Patterns (example: Broker) Special
Design Patterns (example: State)
Small GRASP Patterns (example: Expert) General

Chapter 23: Gang-of-Four Design Patterns v3.2 2

About the GoF Design Patterns
N
(continued)

Three categories.
Creational - How to build problematic objects.
Structural - How to build flexible structures.
Behavioral - How to build powerful behaviors.


Abstract Factory

Problem: Sometimes constructing an object is very Creational
Pattern
complex.
The object is made of many different kinds of complexly
interconnected parts.
The object consists of many parts from one of two or
more sets of compatible parts, but the sets are
incompatible with each other.


Abstract Factory
Creational
Example: Pattern
Constructing user interface widgets in general
(windows, scrollbars, radio button groups, menus,
… ) when there are several widget sets to choose
from (Motif, OpenLook, Presentation Manager, … )


Abstract Factory
Creational
Solution: Create a Pure Fabrication to do the Pattern
construction!

Client

Scrollbar

WidgetFactory

createScrollbar() MotifScrollbar PMScrollbar
createWindow()

Window
MotifWidgetFactory PMWidgetFactory

createScrollbar() createScrollbar()
createWindow() createWindow() MotifWindow PMWindow


Prototype
Creational
Problem: Sometimes constructing an object is Pattern
very complex.
The object is made of many different kinds of
complexly interconnected parts.
There are so many variations and combinations
that the corresponding inheritance hierarchy is
extremely broad.


Prototype (continued)

Creational
Example: Pattern

???

97FordEscortGX 97FordEscortLX 97ChevyCavalierGS 97ChevyCavalierLX

97FordTaurusGX 97FordTaurusLX 97ChevyCorsicaGS 97ChevyCorsicaLX


Prototype (continued)

Solution. Creational
Pattern
Rather than proliferate special-purpose classes, create
a general class and preconfigure a set of constant,
baseline objects.
Clone() these baseline objects as the initial values for your
objects.
AutomobileSpec is the class
ModelCatalog AutomobileSpec
of all of the Prototypes. It has
* the clone() operation. The
actual prototypes are
getModel(name:String) : AutomobileSpec clone() instances of AutomobileSpec
stored by ModelCatalog.

*
Engine Upholstery Doodad

Nitro Fuel Sticky Plush Boring Really Cool
Std Engine
Engine Upholstery Upholstery Doodad Doodad


Singleton
Creational
Problem: When an object is unique, it is tempting to Pattern

globally access it.
But global variables are “bad.”
How can we have direct visibility of the unique object
without global variables?


Singleton (continued)

Creational
Example: Pattern

AutomobileOrder ModelCatalog
???

addFeature() getModel(name:String) : AutomobileSpec
addPackage()

The ModelCatalog is a big, unique object that thousands of
AutomobileOrders would like to easily access.


Singleton (continued)
Creational
Pattern
Solution.
Define the class of the unique object to have a special method,
instance( ).
This method creates the unique object if it does not already exist.
Or, it finds the unique object and returns a reference to it.
A u to m o b ile O r d e r
N o te th e u s e a th e U M L
s t e r e o t y p e " < < s in g le t o n > > " t o
in d ic a te t h a t th e S in g le to n
a d d F e a tu re () p a t t e r n is b e in g u s e d .
a d d P a c k a g e ()

< < s in g le to n > >
M o d e lC a t a lo g M o d e lC a ta lo g P r o x y

th e In s ta n c e
$ in s ta n c e ( ) : M o d e lC a ta lo g ???
g e t M o d e l( n a m e : S t r in g ) : A u t o m o b ile S p e c


Flyweight

Problem: Sometimes it seems necessary to have Structural
Pattern
many copies of a few constant objects.
However, these copies take up a lot of time and space
(creating and destroying them).
If they were shared, performance might improve.


Flyweight
Structural
Example: A Minesweeper game might have Pattern
hundreds of Squares, each with a SquareState.
But, there are only four distinct SquareStates.

contains 
Board Square
1 1.. *, 1.. *
1
has 
1

SquareState

Unmarked Flagged Questionable Uncovered


Flyweight (continued)

Structural
Solution. Pattern

Preconfigure the set of constant objects and make them
available for shared use.
“Shared use” typically requires:
A dispenser object, like an Abstract Factory.
Parameter visibility to the using object so that Flyweight
object can remain constant.



Structural
Pattern

uncover

mark
Unmarked Questionable

uncover mark mark

Uncovered Flagged
uncover

mark uncover



Structural
Pattern

FlyweightFactory SquareState
theStateSet

1
buildStates() * mark(s:Square)
getState(aStateName) : SquareState uncover(s:Square)

mark(s:Square) 2: changeState(next)
:Unmarked :Square

1: next := getNextState()


Proxy
Problem: Sometimes it is desirable not to directly Structural
Pattern
access an object but, instead, access it
through a placeholder or surrogate.
Typically, this need arises from reliability and/or complexity concerns.


Proxy (continued)

Structural
Examples. Pattern
Remote Proxy - A local presentation of a remote
object.
Virtual Proxy - A lightweight object that creates its
heavyweight object on demand.
Protection Proxy - A sentry that guards a secure object.
Device Proxy - A logical device that manages a physical
device.


Proxy (continued)

Structural
Solution. Pattern
Create an abstract class to specify the logical
interface to the object.
Next, create two subclasses.
One is the Proxy and one is the actual object.
Give the Proxy a reference to the actual object and
make it pass messages through after doing its own
work.
See next page.


Proxy (continued)
Structural
Pattern

Printer

status : { online ,
outofpaper , jammed }

print(psFile)

Document PrinterProxy RealPrinter

status : { online , status ??? : { online ,
outofpaper , jammed } outofpaper , jammed }
print()
print(psFile) print(psFile)


Adapter
Problem. Structural
Pattern
Sometimes the interface that you want a client to
use is not the one provided by the supplier.
How can you convert the actual interface of the
supplier to the logical interface of the client?


Adapter (continued)

Structural
Example: Pattern

An AuthorizationRequest is a transaction step, which really
should not be an expert at using a particular kind of modem.

A u t h o r iz a t io n R e q u e s t U S R o b o tic s S p o r ts te r
???

a u th o r iz e ( ) in it ( in it S t r in g )
ta k e O ffh o o k ()
d ia l( p h o n e N u m )
s e n d ( o c t e t S tr in g )
c h e c k C o n n e c t io n ( )
p la c e O n h o o k ( )


Adapter (continued)
Structural
Solution. Pattern
Create an abstract class for a logical interface to
the (category of) device.
Inherit from this interface to create several
adapters, which are experts at using their
corresponding physical devices.
See next page.


Adapter (continued)

Structural
Pattern
AuthorizationRequest

USRModemAdapter USRoboticsSportster

authorize()
adaptee
send(msg,phoneNum) init(initString)
takeOffhook()
SerialCommPort dial(phoneNum)
send(octetString)
checkConnection()
placeOnhook()
send(msg,destination)

3ComEthernetAdapter 3ComEthernet10/100

adaptee
send(msg,address) setParms(...)
send(buffer,address)
broadcast(buffer)


Bridge
Structural
Problem. Pattern
Sometimes, logical concepts can get mixed up with
physical concepts in the same inheritance hierarchy.
This is bad.
Often, this situation arises because a family of
concepts have a related family of implementations.
These family trees can cause problems if they are
mixed.


Bridge (continued)

Structural
Example: Pattern

Square

CoveredSquare UncoveredSquare

Plain Flag QueryMark Blank Number Mine


Bridge (continued)

Solution. Structural
Pattern
Separate the two inheritance hierarchies and link them
by a Bridge.
For example, a reference from the logical abstract
class to the physical abstract class.

Cover Square

Plain Flag QueryMark Transparent Blank Number Mine

− Covers represent the user’s guesses about the state of the board.
− Squares contain the actual state of the board.


Facade
Structural
Problem. Pattern
Often groups of classes (and their instances) are
strongly interdependent on each other.
If a client of a cluster of classes (or their instances)
misuses one element of the cluster, then the whole
cluster might become inconsistent.


Façade (continued)

Structural
Example: Pattern

Scheduler

Statistical
ImageRecognizer Board Schedule
Process Control

Inventory Bin Arm

ChipSpec Manipulator PressureSensor


Facade

Solution. Structural
Pattern
Create a Pure Fabrication to be the interface for the
cluster.
The Façade is a composite object that encapsulates
all of the classes/objects in the cluster.
All clients must now send their requests to the
Façade.
See next page.


Façade (continued)

Structural
Im a g e R e c o g n iz e r R obot
S t a t is t ic a l
P ro c e s s C o n tro l
Pattern

In v e n to ry
A s s e m b le r S u b s y s t e m

<<Facade>>
B o a rd
A s s e m b le r

M a n ip u la t o r A r m S u b s y s t e m

S c h e d u le r
<<Facade>>
M a n ip u la r A r m

S c h e d u le

A rm

B in

M a n ip u la t o r P re s s u re S e n s o r
C h ip S p e c


Observer
Problem. Behavioral
Pattern
It is often extremely useful for one object to monitor
the state of another object.
However, the observed object must actually do all the
work.
Also, with more objects monitoring it, the observed
object gets very highly coupled.


Observer (continued)

Behavioral
Example: Pattern

LIS - Resource
LIS - Patron Information
Information
Design Patterns, Gamma et. al. name: CLarman
1994 Addison-Wesley borrowerID: 63910002
callNumber: 94-34264 resources checked out:
status: checked out Design Patterns:94-34264
Java in a Nutshell:94-7463or

(Observer) (Observer)
???

Book

name
callNumber
status (Subject)


Observer (continued)

Warning. Behavioral
Pattern
The classic GoF Observer solution is outdated and
weak.
It should probably not be used in its classic form, as
described in “Design Patterns.”
The idea of publish-subscribe is useful, but the early
1980’s-inspired GoF solution is limited.
Better to replace it with a modern event-based
publish-subscribe form.
Java delegation event model.


Classic Observer

Solution. Behavioral
Pattern
Generalize the behavior of an Observer as an
abstract class.
Give the observed object a collection of concrete observers.
Let the observed object send a generic notification message to the
observers whenever its state changes.
S u b je c t
O b s e rv e r
a d d O b s e rve r(a n O b s e rve r)
1 *
re m o ve O b s e rve r(a n O b s e rve r) m yO b s e rve rs u p d a te ( )
n o t if y O b s e r v e r s ( )

c a lls u p d a t e ( ) o n a ll o f O b s e r v e r is a n a b s tr a c t
th e O b s e r v e r s in it s c la s s . u p d a te ( ) is d e f in e d
c o lle c t io n in th e C o n c r e t e O b s e r v e r
s u b c la s s
B ook

nam e R e s o u r c e I n f o r m a t io n W in d o w
1 1
c a llN u m b e r
s ta tu s m yR e s o u rc e u p d a te ( )

s e tS ta tu s (n e w S ta tu s )


Classic Observer (continued)

Behavioral
Pattern

What are the weaknesses in Classic Observer?


Java Interface and Event-Based Observers

Subject/ «interface»
Source/ EventListener
Publisher
java.awt.Button

1 «interface»
* ActionListener
addActionListener( ActionListener)
removeActionListener( ActionListener ) actionPerformed(ActionEvent)

processActionEvent( ActionEvent )

adds/removes walks through
listeners from collection and sends MyActionListener
a collection. actionPerformed() Observer/
message to each Listener/
listener Subscriber
actionPerformed(ActionEvent)


Java Interface and Event-Based Observers
(continued)
The delegation event model approach to Observer provides
fine-grained notification and low coupling via interfaces.

«interface» «interface»
EventListener EventListener

java.awt.Button

«interface» 1 1 «interface»
MouseListener * * ActionListener
addActionListener( ActionListener)
mouseReleased(MouseEvent) removeActionListener( ActionListener ) actionPerformed(ActionEvent)

addMouseListener( MouseListener)
removeMouseListener( MouseListener )

DavesMouseListener MyActionListener

mouseReleased(MouseEvent) actionPerformed(ActionEvent)


Command

Problem. Behavioral
Pattern
Sometimes requests need to be treated in a more
complex way than as simple messages between
objects.
Client objects might not know exactly which action should be
performed or who should carry out the task.
Requests might need to be queued, performed at a later time, or
sorted based on priority.
New kinds of requests might be added (even at run time.)


Command (continued)

Behavioral
Example. Pattern


Command (continued)

Pattern
Create an object with a method, execute().
This object is essentially a single method as an object,
except it can carry its own private state.

Menu MenuItem Command
* *
addMenuItem() clicked() execute()

while(moreCommands){ ConcreteCommand1 ConcreteCommand2
commands.execute();
} execute() execute()


State

Problem. Behavioral
Pattern
Sometimes it is necessary for an object’s responses
to messages to vary depending on its state.
Therefore, the meaning of a method depends on the history of
methods previously called.


State (continued)

Example.
Library Information
System

borrowResource(callNum)
enterBorrower(ID)

WaitingForNew Borrowing
Loan Resources

printBorrowReport()


State (continued)

Behavioral
Solution. Pattern
Make the State an abstract class.
Let the specific states inherit from this abstract state.
Give the client object a state object.
See next page.


State (continued)

Behavioral
Pattern

L IS

e n te r B o rro w e r(ID ) L IS S ta te
b o r r o w R e s o u r c e ( c a llN u m )
p r in t B o r r o w R e p o r t ( ) 1 1 e n te rB o rro w e r( ID , L IS )
s e tS ta te (n e w S ta te ) c u r re n tS ta te b o r r o w R e s o u r c e ( C a llN u m , L I S )
r e a lly E n t e r B o r r o w e r ( ID ) p r in t B o r r o w R e p o r t( L IS )
s ta rtN e w L o a n ( ID )
r e a lly B o r r o w R e s o u r c e ( c a llN u m )
r e a lly P r in t R e s o u r c e ( )

W a it in g F o r N e w L o a n L I S S t a t e B o r r o w in g R e s o u r c e s L IS S ta te

e n te rB o r ro w e r (ID ) b o r r o w R e s o u r c e ( C a llN u m )
p r in tB o r r o w R e p o r t( )


State (continued)

Behavioral
The client passes messages through to the state. Pattern

The state chooses its own successor.

enterBorrower(ID) 1:enterBorrower(ID) :WaitingForNew
:LIS
2:idOK:= reallyEnterBorrower(ID) LoanLISState
3[idOK]: startNewLoan(ID) 4:create()
5:setState(newState)
newState:Borrowing
ResourcesLISState


Strategy

Problem. Behavioral
Pattern
Sometimes it can be desirable to have a method
with implementation that changes depending on the
current circumstances.
In other words, it is desirable to use a different algorithm to
accomplish the same task.
The decision must be made at run time.


Strategy (continued)
Behavioral
Pattern
Example:


Strategy (continued)

Pattern
Create an object for the specific method.
Have the client object pass through to the Strategy.

Inbox
Sorter
sort()
sort()
setStrategy()

SubjectQuickSort DateInsertionSort

sort() sort()


Patterns go f

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (15)

Similaire à Patterns go f

Similaire à Patterns go f (20)

Patterns go f