Applying Gang of Four Design Patterns

1
Chapter 26

• Applying Gang of Four Design Patterns

2
The Adapter Pattern

• Problem How to resolve incompatible interfaces,
  or 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.
• Use interfaces and polymorphism to add a level of
  indirection to varying APIs in other components.

3
Fig. 26.1 The Adapter Pattern
4
Fig. 26.2 Using an Adapter

• A particular adapter instance is instantiated for
  the chosen external service.
• Adapts the postSale request to the external
  interface.
• In J2EE, adapters to external services are
  resource adapters.

5
Fig. 26.3 Relating Adapter to GRASP Principles
6
The Factory Pattern

• Problem Who should be responsible for creating
  objects when there are special considerations,
  such as
• complex creation logic,
• a desire to separate the creation
  responsibilities for better cohesion,
• a need for performance-enhancing memory
  management strategies (e.g., object caching).
• Solution Create a Pure Fabrication object
  called a Factory that handles the creation.

7
Fig. 26.5 A Factory reads a class name to create
8
The Singleton Pattern

• Problem How to provide visibility to a utility
  object that needs to be accessed from many places
  in the code, without passing it as a parameter in
  many places.
• Solution Define a single static instance of the
  class and a static method of that class that
  returns the singleton.
• Exactly one instance of the class.
• Global visibility to a single access point.
• accountingAdapter ServicesFactory.getInstance().
  getAccountingAdapter()

9
Fig. 26.6 The Singleton pattern in
ServicesFactory
10
Fig. 26.7 Implicit getInstance message in UML
11
Lazy vs. Eager Initialization

• Lazy initialization create when needed.
• A critical section in multi-threaded apps.
• public static synchronized ServicesFactory
  getInstance()
• if ( instance null )
• instance new ServicesFactory() //
  critical section
• return instance
• Eager initialization static initialization.
• public class ServicesFactory
• private static ServicesFactory instance
• new ServicesFactory()
• public static ServicesFactory getInstance()
• return instance

12
Fig. 26.8 Adapter, Factory, and Singleton in POS
13
The Strategy Pattern

• Problem How to design for varying but related
  algorithms or policies, and for the ability to
  change them.
• E.g., pricing strategies for a sale 10 off all
  sales, 10 off if total gt 200, etc.
• Solution Define each algorithm/policy/ strategy
  in a separate class, with a common interface.
• E.g., polymorphic getTotal( s Sale) method that
  applies a discounting rule.

14
Fig. 26.9 Pricing Strategy classes
15
Fig. 26.10 Strategy in collaboration with
context object

• Context object the object to which the Strategy
  object applies its algorithm.
• Context object passes reference to itself to
  strategy object to give it parameter visibility
  for collaboration.

16
Fig. 26.11 Visibility to strategy via an
interface
17
Fig. 26.12 Factory for strategies
18
Fig. 26.13 Creating a Strategy

• Strategy Factory should re-read external property
  or data store and create a new Strategy object
  each time it is called (no object caching).
• Strategy can change frequently (e.g., hourly).
• Can read discount percentages from data store.

19
The Composite Pattern

• Problem How to treat a group or composition
  structure of objects the same way
  (polymorphically) as a non-composite (atomic)
  object.
• E.g., there may be multiple, conflicting pricing
  policies and a conflict resolution strategy.
• Solution Define classes for composite and
  atomic objects so that they implement the same
  interface.

20
Fig. 26.14 The Composite pattern for pricing
strategies
21
Fig. 26.15 Collaboration with a Composite
22
Fig. 26.16 Abstract superclass and method
23
Creating Pricing Strategies

• The composite pricing strategy object contains a
  group of multiple/conflicting pricing strategies.
  When do we create these strategies?
• Current store-defined discount when the sale is
  created.
• Customer type discount when the customer type
  is communicated to the POS.
• Product type discount when the product is
  entered to the sale.

24
Fig. 26.17 Creating a Composite Strategy
25
Fig. 26.18 Pricing strategy for a customer
discount
26
Fig. 26.19 Pricing strategy for customer discount
27
IDs to Objects

• It is common in object design to transform keys
  and IDs for things into true objects.
• Often done shortly after ID/key enters domain
  layer from the UI layer.
• Encapsulated information
• Possibility of behavior
• Benefits often seen as the design grows.
• Could be formulated as a separate pattern.

28
Pass Aggregate Object as Parameter

• Why not pass a composite object containing
  Customer and PricingStrategy to the factory,
  instead of passing Sale and having factory ask
  for Cust. and Strategy?
• Avoid extracting child objects out of parent or
  aggregate objects and then passing child objects.
• Increases flexibility factory can collaborate
  with entire Sale in ways we might not anticipate.
• Reduces need to anticipate what factory needs.

29
Façade Pattern

• Problem A common, unified interface to a
  disparate set of implementations or interfaces (a
  subsystem) is required.
• Solution Define a single point of contact to
  the subsystem a façade that wraps the
  subsystem and is responsible for collaborating
  with subsystem components.
• front-end object
• single point of entry for services of subsystem
  (often a Singleton)

30
Fig. 26.20 Façade for a rule engine
31
The Observer (Publish-Subscribe) Pattern

• Problem Different kinds of subscriber objects
  are interested in the state changes or events of
  a publisher object, and want to react in their
  own unique way when the publisher generates an
  event.
• Solution Define a subscriber or listener
  interface, implemented by subscribers. Publisher
  can dynamically register subscribers interested
  in an event and notify them when an event occurs.

32
Fig. 26.21 Updating interface when sale total
changes
33
Fig. 26.22 The Observer pattern
34
Fig. 26.23 SaleFrame1 subscribes to publisher
Sale
35
Fig. 26.24 Sale publishes property event to
subscibers
36
Fig. 26.25 Subscriber receives notification of
event
37
Observer, Publish-Subscribe, Delegation Event
Model

• Observer idiom from Smalltalk
• Listener/subscriber observes an event.
• Originally called publish-subscribe.
• One object publishes events (e.g., Sale)
• Interested objects can subscribe or register
  interest in an event.
• Delegation Event Model in Java.
• Publisher delegates handling of events to
  listeners/subscribers.

38
Fig. 26.26 Who is observer, subscriber,
publisher?
39
Fig. 26.27 Observer applied to alarm events