GangofFour Design Patterns

1
Gang-of-Four Design Patterns
2
About the GoF Design Patterns

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

3
About the GoF Design Patterns (continued)

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

4
Abstract Factory
CreationalPattern

• Problem Sometimes constructing an object is very
  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.

5
Abstract Factory
CreationalPattern

• Example 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, )

6
Abstract Factory
CreationalPattern

• Solution Create a Pure Fabrication to do the
  construction!

7
Prototype
CreationalPattern

• Problem Sometimes constructing an object is 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.

8
Prototype (continued)
CreationalPattern

• Example

9
Prototype (continued)
CreationalPattern

• Solution.
• 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.

10
Singleton
CreationalPattern

• Problem When an object is unique, it is tempting
  to globally access it.
• But global variables are bad.
• How can we have direct visibility of the unique
  object without global variables?

11
Singleton (continued)
CreationalPattern

• Example

The ModelCatalog is a big, unique object that
thousands of AutomobileOrders would like to
easily access.
12
Singleton (continued)
CreationalPattern

• 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.

13
Flyweight
StructuralPattern

• Problem Sometimes it seems necessary to have
  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.

14
Flyweight
StructuralPattern

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

15
Flyweight (continued)
StructuralPattern

• Solution.
• 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.

16
Flyweight (continued)
StructuralPattern
17
Flyweight (continued)
StructuralPattern
18
Proxy
StructuralPattern

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

19
Proxy (continued)
StructuralPattern

• Examples.
• 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.

20
Proxy (continued)
StructuralPattern

• Solution.
• 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.

21
Proxy (continued)
StructuralPattern
22
Adapter
StructuralPattern

• Problem.
• 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?

23
Adapter (continued)
StructuralPattern

• Example

An AuthorizationRequest is a transaction step,
which really should not be an expert at using a
particular kind of modem.
24
Adapter (continued)
StructuralPattern

• Solution.
• 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.

25
Adapter (continued)
StructuralPattern
26
Bridge
StructuralPattern

• Problem.
• 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.

27
Bridge (continued)
StructuralPattern

• Example

28
Bridge (continued)
StructuralPattern

• Solution.
• 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.

• Covers represent the users guesses about the
  state of the board.
• Squares contain the actual state of the board.

29
Facade
StructuralPattern

• Problem.
• 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.

30
Façade (continued)
StructuralPattern

• Example

31
Facade
StructuralPattern

• Solution.
• 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.

32
Façade (continued)
StructuralPattern
33
Observer
BehavioralPattern

• Problem.
• 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.

34
Observer (continued)
BehavioralPattern

• Example

35
Observer (continued)
BehavioralPattern

• Warning.
• 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 1980s-inspired GoF solution is limited.
• Better to replace it with a modern event-based
  publish-subscribe form.
• Java delegation event model.

36
Classic Observer
BehavioralPattern

• Solution.
• 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.

37
Classic Observer (continued)
BehavioralPattern

• What are the weaknesses in Classic Observer?

38
Java Interface and Event-Based Observers
39
Java Interface and Event-Based Observers
(continued)

• The delegation event model approach to Observer
  providesfine-grained notification and low
  coupling via interfaces.

40
Command
BehavioralPattern

• Problem.
• 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.)

41
Command (continued)
BehavioralPattern

• Example.

42
Command (continued)
BehavioralPattern

• Solution.
• 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.

43
State
BehavioralPattern

• Problem.
• Sometimes it is necessary for an objects
  responsesto messages to vary depending on its
  state.
• Therefore, the meaning of a method depends on the
  history of methods previously called.

44
State (continued)

• Example.

45
State (continued)
BehavioralPattern

• Solution.
• 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.

46
State (continued)
BehavioralPattern
47
State (continued)
BehavioralPattern

• The client passes messages through to the state.
• The state chooses its own successor.

48
Strategy
BehavioralPattern

• Problem.
• 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.

49
Strategy (continued)
BehavioralPattern

• Example

50
Strategy (continued)
BehavioralPattern

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