GoF Design Patterns
GoF Design Patterns
“Gang of Four” Design Patterns
• Adapter
• Factory
• Singleton
• Observer (Publish-Subscribe)
Adapter Pattern
Problem: How to resolve incompatible interfaces,
or how to provide a stable interface to similar
components with different interfaces.
Solution: Convert the original interface of a
component into another interface, through an
intermediate adapter object.
Note: the Adapter pattern is an application of
Polymorphism
Adapter Pattern
Example: POS needs to adapt several kinds
of external third-party services: tax
calculators, credit authorization services,
inventory systems, accounting systems.
Each has a different API which can’t be
changed.
«interface» Adapters use interfaces and
ITaxCalculatorAdapter polymorphism to add a level of
indirection to varying APIs in other
getTaxes( Sale ) : List of TaxLineItems components.
TaxMasterAdapter GoodAsGoldTaxPro
Adapter
getTaxes( Sale ) : List of TaxLineItems
getTaxes( Sale ) : List of TaxLineItems
«interface» «interface»
IAccountingAdapter ICreditAuthorizationService
Adapter
postReceivable( CreditPayment )
postSale( Sale ) requestApproval(CreditPayment,TerminalID, MerchantID)
... ...
«interface»
IInventoryAdapter
SAPAccountingAdapter GreatNorthernAccountingAdapter
...
postReceivable( CreditPayment ) postReceivable( CreditPayment )
postSale( Sale ) postSale( Sale )
... ...
:Register : SAPAccountingAdapter
makePayment
...
SOAP over
HTTP
postSale( sale )
xxx «actor»
: SAPSystem
the Adapter adapts to
interfaces in other components
Adapter Pattern
Note: Adapter pattern follows GRASP
principles: Polymorphism, Protected
Variation, Indirection
conceptual connection among GRASP
principles and Adapter pattern
Conceptual connection among GRASP principles and Adapter
pattern
Low coupling is a way to achieve protection at a Protected Variation GRASP
variation point. Mechanism Principles
Polymorphism is a way to achieve protection at a
variation point, and a way to achieve low coupling.
An indirection is a way to achieve low coupling. Low Coupling High Cohesion
Mechanism Mechanism
The Adapter design pattern is a kind of Indirection
and a Pure Fabrication, that uses Polymorphism.
Polymorphism Indirection Pure
Example Mechanism Fabrication
GoF Design
Adapter Patterns
Factory Pattern
Problem: Who should be responsible for
creating objects when there are special
considerations such as complex creation
logic, a desire to separate creation
responsibilities for better cohesion, etc.?
Solution: Create a Pure Fabrication object
called a Factory that handles the creation.
Factory Pattern
• Technically not a GoF pattern
• A variation of GoF Abstract Factory
pattern
Fig. 26.5
ServicesFactory note that the factory methods
return objects typed to an
accountingAdapter : IAccountingAdapter interface rather than a class, so
inventoryAdapter : IInventoryAdapter that the factory can return any
taxCalculatorAdapter : ITaxCalculatorAdapter implementation of the interface
getAccountingAdapter() : IAccountingAdapter
getInventoryAdapter() : IInventoryAdapter
getTaxCalculatorAdapter() : ITaxCalculatorAdapter
...
if ( taxCalculatorAdapter == null )
{
// a reflective or data-driven approach to finding the right class: read it from an
// external property
String className = System.getProperty( "taxcalculator.class.name" );
taxCalculatorAdapter = (ITaxCalculatorAdapter) Class.forName( className ).newInstance();
}
return taxCalculatorAdapter;
Factory Pattern (26.4)
Note: In Fig. 26.5 the implementation of
ServicesFactory illustrates data-driven
design – a form of Protected Variation
Factory Pattern (26.4)
Idea: Define an object whose purpose is to
create objects
Benefits:
– Separate the responsibility of complex
creation into cohesive helper objects
– Can provide object caching (e.g. having only
one random number generator)
Singleton Pattern (26.5)
Problem: Exactly one instance of a class is
allowed. Objects need a global and single
point of access.
Solution: Define a static method of the
class that returns the singleton:
getInstance()
Singleton Pattern (26.5)
Consider the factory and how it is accessed – who creates
the factory?
– Only want one instance of the factory
– Methods may need to be called from various places => how to
make single instance of the factory globally visible
Could pass the ServicesFactory instance around as a
parameter whenever visibility is required or initialize all
objects that need it with a permanent reference to it
Singleton – supports global visibility or a single access
point to a single instance
Fig. 26.6
UML notation: this '1' can optionally be used to
indicate that only one instance will be created (a
singleton)
1
ServicesFactory
UML notation: in a instance : ServicesFactory singleton static
class box, an attribute
underlined attribute or accountingAdapter : IAccountingAdapter
method indicates a inventoryAdapter : IInventoryAdapter
static (class level) taxCalculatorAdapter : ITaxCalculatorAdapter
member, rather than singleton
an instance member getInstance() : ServicesFactory static
method
getAccountingAdapter() : IAccountingAdapter
getInventoryAdapter() : IInventoryAdapter
getTaxCalculatorAdapter() : ITaxCalculatorAdapter
...
// static method
public static synchronized ServicesFactory getInstance()
{
if ( instance == null )
instance = new ServicesFactory()
return instance
}
Singleton Pattern (26.5)
Note: concurrency control in
ServicesFactory – making getInstance()
synchronized
Fig. 26.8 shows how Adapter, Factory,
Singleton patterns are used in design
Fig. 26.8 1
:Store
:ServicesFactory
create
create :Register
accountingAdapter =
getAccountingAdapter
create : SAPAccounting
Adapter
accountingAdapter:
:Register
SAPAccountingAdapter
makePayment
create(cashTendered) : Payment SOAP over
HTTP
postSale( sale )
xxx «actor»
: SAPSystem
Observer Pattern (26.10)
Also known as Publish-Subscribe Pattern
Problem: Different kinds of subscriber objects are
interested in state changes or events of a publisher
object and want to react in their own unique way when
the publisher generates an event. The publisher wants
to maintain low coupling to the subscribers.
Solution: Define a subscriber or listener interface.
Subscribers implement the interface. The publisher can
dynamically register subscribers who are interested in an
event and notify them when an event occurs.
Observer Pattern (26.10)
Example: Want a GUI window to refresh
(update) its display of sale total when the
total changes
See Fig. 26.21
Fig. 26.21
Goal: When the total of the sale
changes, refresh the display with
the new value
Sale
total
...
setTotal( newTotal )
...
Observer Pattern (26.10)
Example (cont):
Simple solution – when Sale changes its
total the object sends a message to the
window telling it to refresh its display
Problem – high coupling between domain
objects and UI objects
Observer Pattern (26.10)
Example (cont):
Want to be able to easily replace UI
objects or even add other UI objects that
can be notified of this event
That is, want model-view separation
Model objects shouldn’t know about view
objects => Protected Variations with
respect to a changing user interface
Fig. 26.22
{ {
for each PropertyListener pl in propertyListeners propertyListeners.add( lis );
pl.onPropertyEvent( this, name, value ); }
}
Sale
addPropertyListener( PropertyListener lis )
publishPropertyEvent( name, value )
setTotal( Money newTotal )
...
{
total = newTotal;
publishPropertyEvent( "sale.total", total );
}
javax.swing.JFrame propertyListeners
*
... «interface»
setTitle() PropertyListener
setVisible()
... onPropertyEvent( source, name, value )
{
if ( name.equals("sale.total") )
saleTextField.setText( value.toString() );
}
SaleFrame1
onPropertyEvent( source, name, value ) {
sale.addPropertyListener( this )
initialize( Sale sale ) ...
... }
Observer Pattern (26.10)
Steps (p. 465)
1. Define an interface PropertyListener with operation
onPropertyEvent
2. Define window (SaleFrame1) to implement the interface
3. When SaleFrame1 is initialized pass it the Sale instance from
which it is displaying the total
4. SaleFrame1 registers to the Sale instance for notification of
“property events” via the addPropertyListener message
5. Note that the Sale does not know about SaleFrame1 objects; it
only knows about objects that implement the PropertyListener
interface. (This lowers the coupling of the Sale to the window
– the coupling is only to an interface, not to a GUI class.)
6. The Sale instance is the publisher of “property events”. When
the total changes, it iterates across all subscribing
PropertyListeners, notifying each
Observer Pattern (26.10)
Notes:
– The SaleFrame1 object is the
observer/subscriber/listener
– Sale is the publisher of property events
– Sale adds SaleFrame1 object to its list of
PropertyListener subscribers – Fig. 26.23
Fig. 26.23
sf : SaleFrame1 propertyListeners :
s : Sale
List<PropertyListener>
initialize( s : Sale )
addPropertyListener( sf )
add( sf )
Observer Pattern (26.10)
Notes:
– When the Sale total changes it iterates over
all registered subscribers and sends the
onPropertyEvent message to each – Figs.
26.24, 26.25
Fig. 26.24
s :Sale propertylisteners[ i ] :
PropertyListener
setTotal( total )
publishPropertyEvent
( "sale.total", total )
loop onPropertyEvent( s, "sale.total", total )
Fig. 26.25
Since this is a polymorphic operation implemented by
this class, show a new interaction diagram that starts saleTextField
: SaleFrame1
with this polymorphic version : JTextField
onPropertyEvent( source, name, value )
setText( value.toString() )
UML notation: Note this little expression within the
parameter. This is legal and consise.
Fig. 26.26
Sale
addPropertyListener( PropertyListener lis ) publishes events to
publishPropertyEvent( name, value ) observers/listeners/
subscribers
setTotal( Money newTotal ) registers them when
... they ask to subscribe
javax.swing.JFrame propertyListeners
*
... «interface»
setTitle() PropertyListener
setVisible()
... onPropertyEvent( source, name, value )
listens for events
SaleFrame1 observes events
subscribes to notification of events
onPropertyEvent( source, name, value )
initialize( Sale sale )
...
Who is the observer, listener, subscriber, and publisher?
Observer Pattern (26.10)
Notes:
– Sale is coupled to view object but only loosely since it
only knows subscribers as implementing the
PropertyListener interface
– In Java this was called Delegation Event Model
Observer pattern is basis for GUI widget event
handling in both Java (AWT & Swing) and .NET
Widgets are publishers of events, other objects
can register as listeners
Observer Pattern (26.10)
Example of AlarmClock:
AlarmClock is publisher of alarm events
Different types of objects can register as
listeners and react to same alarm event in
their own ways
Fig. 26.27
{
for each AlarmListener al in alarmListeners
al.onAlarmEvent( this, time );
} {
alarmListeners.add( lis );
}
AlarmClock
addAlarmnListener( AlarmListener lis )
publishAlarmEvent( time )
setTime( newTime ) {
... time = newTime;
if ( time == alarmTime )
publishAlarmEvent( time );
}
javax.swing.JFrame alarmListeners
*
... «interface»
setTitle() AlarmListener
setVisible()
... onAlarmEvent( source, time )
AlarmWindow Beeper ReliabilityWatchDog
onAlarmEvent( source, time ) onAlarmEvent( source, time ) onAlarmEvent( source, time )
... ... ...
{ {
{
display notification dialog check that all required processes
beep
box are executing normally
}
} }
Summary
• Singleton:
– Factory for a singular (sole) instance
– Ensures that only one object of a particular class is
ever created.
• Adapter:
– Translator adapts a server interface for a client
– Used to provide link between two or incompatible
types by wrapping with a class that supports the
interface required by the client.
Observer Pattern:
– Used to allow an object to publish changes to its
state.
– Other objects subscribe to be immediately notified
of any changes.
– Dependents update automatically when subject
changes
• Factory:
– Factory for building related objects
– Used to provide client with a set of related and
dependent objects.
