Kevlin Henney Frank Buschmann - HSR-Wiki

Beyond the
Gang of Four
Kevlin Henney
Curbralan Limited
kevlin@curbralan.com
Frank Buschmann
Siemens AG
frank.buschmann@siemens.com

Agenda
• Objectives
�� Consider the pattern concept beyond the Gang of Four
• Contents
�� Introduction
�� Missing ingredients
�� Alternative solutions
�� Scope and granularity
�� Singleton
�� Outroduction
2

Introduction
• Intent
�� Outline the goal of this tutorial
• Content
�� The Gang of Four
�� Our goal
�� Misconceptions about the Gang of Four
�� Issues in the Gang of Four
�� Confusing map and territory
3

The Gang of Four
• Design Patterns has had a profound effect on what
is considered to be design
�� Highly influential and a useful starting point
• But it has also restricted the expectations and
design vocabulary of many programmers
The The enormous success of of design patterns is is a testimonial to to the the commonality
seen seen by by object object programmers. The The success of of the the book book Design Patterns,
however, has has stifled stifled any any diversity in in expressing these these patterns.
Kent Kent Beck
Beck
4

Our Goal
• Place Design Patterns into perspective
�� Historical, social and technical
• Recognise its strengths; appreciate its limitations
�� Nothing is perfect and everything has limitations, but in
some cases more problems are caused than in others
• Deconstruct and reconstruct good — and better —
design practices associated with the GoF catalogue
�� Place the individual patterns into a broader and more
pattern-oriented pattern oriented context
5

Twenty-Three Twenty Three Patterns in View
• For some programmers, there are only twenty-
three patterns
�� This tutorial is as much about the magic number 23 as it
is about the content of that 23
• The aim is to open up some of the 23 to show that,
in many cases, they hide more than they reveal
�� Patterns that are missing by implication or
by experience
�� Patterns hiding within patterns
6

Gang-of Gang of-Four Four Design Style
• Programming to an interface not an
implementation
�� Inheritance is used primarily for establishing interfaces
rather than for subclassing of implementation
• Extensive use of forwarding ('delegation') in
preference to inheritance of implementation
• Emphasis on localised, general framework design
above the level of the individual class
�� Programming in the large is not really addressed, and
idiomatic practices are seen as peripheral
7

Misconceptions about GoF
• Misconceptions are about individual patterns as
well as about the catalogue as a whole
�� The motivating example is the pattern
�� The diagram is the pattern
�� The source code is the pattern
�� Copy-and Copy and-paste paste solutions
�� Patterns are applicable only to OO design
�� There are only 23 patterns
23 23 patterns you you can can cut cut and and paste into into your your own own design documents.
Blurb Blurb on on back back cover cover of of Design Design Patterns CD
CD
8

References and Blueprints?
• A motivating example is sometimes taken to be
the reference implementation for the pattern
�� Also, the distilled essence outlined as the general
solution is not a reference implementation
• The mistaken idea that a pattern is a blueprint or
simply parameterizable design is also common
blueprint as as a metaphor for for a design or or plan is is much overworked. If If
the the temptation to to use use it it is is irresistible, at at least remember that thata a
blueprint is is a completed plan, not not a preliminary one. one.
Bill Bill Bryson
Bryson
9

Pattern Structure Issues
• If a pattern is a solution to a problem, where's the
problem statement and solution description?
�� The intent of the intent is unclear — sometimes it
describes problem, sometimes solution, sometimes both
�� The role of applicability is vague — sometimes it plays
the role of context and forces... sometimes not
�� The solution structure is not just the structure section,
and there is no clear statement of what the solution is
�� Sometimes the example and sample code carry the
weight of the pattern
10

Catalogue Issues
• Of course, there is the effect of time
�� The 23 patterns identified are not the ones we would
necessarily consider the most important today
• How useful or meaningful is the object- object and class-
scope classification?
�� What does it mean and how can Adapter be both?
�� Seems to offer more interference than reference
• The notion of pattern purpose is not always clear
�� Creational seems obvious, but what about structural?
structural
11

Confusing Map and Territory?
• What is the GoF catalogue map about?
�� It's not about uses relationships... except when it is
�� The uses shown are not often the useful uses
• Many of the important relationships mentioned in
the patterns are not included
�� Many of the unimportant ones are
• The emphasis of the map is sometimes misleading
�� Which is the most important pattern?
�� Which are the most isolated patterns?
12

A Map... of What?
So lonely?
Connection not
mentioned in Composite
Most important pattern?
What is the starting point
here?
No relationship with
Builder is acknowledged
A generative statement!
13

Into the Gang of Four
• The aim is to pin down...
�� Missing ingredients in some existing GoF
patterns, which would make the patterns
richer and more complete
�� Alternative solutions that complement GoF
patterns, that will make our design vocabulary
richer and more complete
�� The proper scope and granularity for many
of the patterns, so that they do one thing well
�� Singleton, which is (in) a class of its own
14

Missing Ingredients
• Intent
�� Discover what is missing from some common patterns
and complete them
• Content
�� History and hindsight
�� Command and Command Processor
�� Factory Method and Disposal
Method
�� Completing factories
�� Linking Iterator with Disposal Method
15

History and Hindsight
• Experience is often responsible for letting us spot
certain omissions
�� Whether omissions in individual patterns or from
related groups of patterns
• An eye for cohesion lets us spot other omissions
�� What do we repeatedly include when applying a
pattern, i.e. what additional patterns are there?
History rarely happens in in the the right order or or at at the the right time,
but but the the job job of of a historian is is to to make it it appear as as if if it it did. did.
James James Burke
Burke
16

The Command Pattern
• The reification of a method call, with context, into
an object that can be passed around by reference
�� Decoupling the decision of what to execute from the
decision of when to execute
• Based on inversion of control flow and encourages
decoupling in both time and space
Command
Encapsulate a request as as an an object, thereby letting you you parameterize
clients with with different requests, queue or or log log requests, and and support
undoable operations.
17

Much Undo about Something
• Taking the common example of supporting undo
in a GUI application...
�� And remembering that there is quite a bit more to
Command than 'undo' :-) :
• How do we support multiple undo?
�� Does the additional code find its way into the
Command objects, or into the
Command user, or...?
�� How is history policy handled?
18

Introducing a Processor
• A separate processor object can handle the
responsibility for multiple Command objects
�� This responsibility should clutter neither the Command
hierarchy nor the client code
Client Command
Processor
doCommand
undoLast
*
Command
19

Implementation Detail?
• Is it the case that introducing a processor object is
simply a detail of the implementation?
�� The resulting design is not sufficiently different from
the single undo to warrant noting the design variation
�� Or, although different, the difference is not important
enough to note, i.e. it's a minor detail
�� Or, you would always use this approach, regardless, so
the design technique is already a part of Command
�� Or, this design is specific to 'undo' rather than being a
common use within Command
20

Or Pattern?
• Or is it the case that the use of a processor is a
recurring design that addresses specific forces?
�� The resulting design has a sufficiently different
architecture and properties to the single undo variant
�� The applicability of this design technique is contingent
on requirements, so not all uses of Command need to or
should employ it
�� It has broader scope than just being applied in
the context of Command 'undo'
21

The Command Processor Pattern
• Command Processor complements Command by
handling responsibility for execution policy
�� It is an additional and complementary microarchitecture
for Command
�� It recurs in many situations beyond the 'undo' example
Command Processor
Separate the the request for for a service from from its its execution. A command
processor component manages requests as as separate objects, schedules
their their execution, and and provides additional services such such as as the the storing of of
request objects for for later later undo.
22

The Factory Method Pattern
• Factory Method is itself balanced and contained
with respect to its goal
�� This is true in both the specific GoF view of Factory
Method and also more generalised views of the pattern
• The question of completeness arises when a
Factory Method is used as part of another pattern
Factory Method
Define an an interface for for creating an an object, but but let let subclasses decide
which class class to to instantiate. Factory Method lets lets a class class defer instantiation
to to subclasses.
23

Factory Method Sketch
• Mirroring the hierarchy of what is created...
�� An interface for creation is provided
�� The responsibility for creation is deferred to an
implementing subclass
Client
Creator
factoryMethod
Concrete
Creator
factoryMethod
«create»
Product
Concrete
Product
24

The Abstract Factory Pattern
• There is a meaningful and generative relationship
between Abstract Factory and Factory Method
�� Scaling from the creation of individual objects to the
creation of whole families of objects
• A concrete factory implements a number of
related Factory Methods according to an interface
Abstract Factory
Provide an an interface for for creating families of of related or or dependent objects
without specifying their their concrete classes.
25

The Disposal Method Pattern
• Factories can leave unresolved lifetime and
resource management issues
�� Who cleans up factory products after use?
�� How can you reduce dynamic memory usage?
• A Disposal Method can provide an answer
Disposal Method
Encapsulate the the concrete details of of object disposal by by providing an an
explicit method for for clean up up instead of of letting object users either
abandon objects to to the the tender mercies of of the the garbage collector or or
terminate them them with with extreme prejudice and and delete.
26

Disposal Method Sketch
• Reflecting the application of Factory Method...
�� The responsibility for disposal — whether destruction
or recycling — is collocated with the creation
Client
Creator
factoryMethod
disposalMethod
Concrete
Creator
factoryMethod
disposalMethod
«create»
«destroy»
Product
Concrete
Product
27

Linking Factory and Disposal
• Factory Method and Disposal Method are
complementary with respect to local symmetry
�� One completes the other by addressing unresolved
questions in the lifecycle of an object
• Together they form a generative phrase
�� Where one pattern strongly suggests the application of
the next as part of its structure
Factory
Method
Disposal
Method
28

Completing Other Factories
• Consideration of disposal becomes a natural
consequence of considering creation
�� Any creational pattern becomes more complete and
more useful by raising the question of disposal
Abstract
Factory
Prototype
Builder
Factory
Method
Disposal
Method
29

Iterators and Disposal
• Iterator embodies a fine-grained fine grained commodity
�� If usage is decoupled dynamically from the concrete
type, a Factory Method resolves the creational tension
�� In unmanaged resource situations a Disposal Method
addresses lifetime completion
• However, this design phrase is context specific
�� It makes little sense outside its intended scope
Iterator
Factory
Method
Disposal
Method
30

Alternative Solutions
• Intent
�� Identify the complements of some common patterns
• Content
�� A one-way one way system?
�� Proxy and Half-Object Half Object + Protocol
�� Iterator
�� Combined Method, Batch Method
and Enumeration Method
�� Objects for States, Collections for
States and Methods for States
31

A One-Way One Way System?
• With the exception of the creational patterns, each
problem type has only one GoF pattern against it
�� Some people see this as a strength, reducing their
design options instead of creating a design dialogue
�� Gives the impression that there is only one solution per
general problem, and the one in the book is that one
• Good design involves making informed choices
�� Patterns should communicate those choices
�� Arbitrarily reducing the available degrees of freedom at
the expense of suitability is not a sound approach
32

The Proxy Pattern
• A Proxy controls and manages access to a target
object, forwarding requests to it
• The pattern has many applications and variations
�� E.g. remote access transparency in a distributed object
system, smart pointers for memory management in C++
Proxy
The The Proxy design pattern makes the the clients of of a component communicate
with with a representative rather than than to to the the component itself. Introducing
such such a placeholder can can serve many purposes, including enhanced
efficiency, easier access and and protection from from unauthorized access.
33

Typical Proxy Sketch
• The role of the interface is central and the roles in
the communication are static
�� Each object or role is a whole, and not subdivided
client
implementor
operation
«interface»
interface
operation
target
«implements»
proxy
operation
Signature and
contract placeholder
Forward operation
request to target
Actual implementation
of operation
34

Partitioning Issues
• For Proxy to be effective a clear separation is
needed between the role of target and user
�� These two roles must be physically and functionally
cohesive, otherwise the boundary cuts across roles
• However, sometimes an object needs to appear to
be in multiple address spaces simultaneously
�� And the implementation of its behaviours must also be
physically distributed...
�� But yet it must appear as a single whole
35

Half-Object Half Object + Protocol (HOPP)
• Divide the physical object across address spaces
�� But retain and manage the conceptual object as a whole
Objects in first
address space
Synchronisation
Protocol
Half Object Half Object
Object
Objects in second
address space
36

The Iterator Pattern
• Classically defined in terms of separating the
responsibility for iteration from its target
�� The knowledge for iteration is encapsulated in a
separate object from the target
�� Rendered idiomatically in different languages, e.g. STL
in C++ and (more than once) in Java's standard library
Iterator
Provide a way way to to access the the elements of of an an aggregate object sequentially
without exposing its its underlying representation.
37

Iterator Configuration Sketch
• There are four essential, elementary operations
associated with an Iterator's behaviour
�� Initialising an iteration
�� Checking a completion condition
�� Accessing a current target value
�� Moving to the next target value
Collection
createIterator() : Iterator
Type
1
«create»
*
Iterator
Type
finished() : Boolean {query}
value() : Type {query}
next()
38

Concurrency Issues
• Synchronisation is required to ensure consistent
and coherent state
�� This cannot be handled adequately by the Iterator client
• Property-style Property style programming is inappropriate
�� There is a mismatch in granularity and coherence
client 1 servant
client 2
39

The Combined Method Pattern
• Applying it gives slightly coarser granularity than
the separated methods of a sequential Iterator
�� Aligns and groups the unit of failure, synchronisation
and common use
�� Improves the encapsulation of collection use, isolating
the client from unnecessary details
Combined Method
Combine methods that that are are commonly used used together to to guarantee
correctness and and improve efficiency in in threaded and and distributed
environments.
40

Distribution Issues
• Concurrency is implicit
• Operation invocations are no longer trivial
�� Communication can dominate computation
�� Partial failure is almost inevitable
client
servant
Cost of communication
41

The Batch Method Pattern
• Iterated simple methods use up bandwidth
�� Spending far more time in communication than in
computation
• Provide the repetition in a data structure
�� More appropriate granularity that reduces
communication and synchronisation costs
Batch Method
Group multiple collection accesses together to to reduce the the cost cost of of multiple
individual accesses in in a distributed environment.
42

Batched (or Chunky) Iterators
• A combination of these patterns recurs in
distribution and component-based component based design
�� A compound design that addresses many requirements
Batch
Method
Iterator
Combined
Method
Factory
Method
Disposal
Method
43

The Enumeration Method Pattern
• An inversion of the basic Iterator design
�� Iteration is encapsulated within the collection
�� Collection stateless with respect to iteration
• A method on the collection that receives a
Command, which it then applies to its elements
�� Idiomatic iteration in Smalltalk based on block objects
Enumeration Method
Support encapsulated iteration over over a collection by by placing responsibility
for for iteration in in a method on on the the collection. The The method takes a Command
object that that is is applied to to the the elements of of the the collection.
44

Enumeration Method Sketch
• Has very different trade-offs trade offs when compared to
the Iterator approach
�� Client is not responsible for loop housekeeping details
�� Synchronisation can be provided at the level of the
whole traversal rather than for each element access
Collection
Type
enumerationMethod(Command)
Loop administration is handled in
the implementation of the
enumerationMethod
Command
executeOn(Type)
Type
Loop body is now provided
as the implementation of the
executeOn method
45

The State Pattern
• Also known as the Objects for States pattern
�� A name that better reflects the reification that occurs in
the design
• It can lead to a proliferation of classes and a
complex design if applied carelessly
�� Not inappropriate in all cases, but in many situations
the design can be overly complex
State
Allow an an object to to alter alter its its behavior when its its internal state state changes. The The
object will will appear to to change its its class.
46

What is the Real Intent?
• The documented intent can be considered vague
and a little misleading
�� An object changing its behaviour in response to an
internal state change is hardly news
�� Is the emulation of dynamic inheritance really the best
way to motivate the pattern?
• As a result, many programmers ignore either the
intent or the pattern as a whole
�� Now is the winter of our missed intent... :-)
:
47

Complexity and Overkill
• The pattern is complex, but the detail offered does
not adequately cover that complexity
�� The implementation is incomplete and, therefore,
unclear and unmotivating for many programmers
• In many cases the pattern is overkill
�� Sometimes a flag or table really
is the simplest, clearest and
most elegant thing that
could possibly work
48

The Other State Patterns
• However, in spite of its common name, the State
pattern is not the only game in town
�� A common misconception is that any problem
associated with a state model should
necessarily be realised using Objects for States
�� The name suggests the problem domain rather
the solution, and as such appears to address
all variations
49

A Note on Naming
• As with variables, naming is important
�� Should be memorable, usable and distinct
�� Should be based on something that characterises the
proposed solution rather than the problem
• The GoF naming style is based on choosing
the name of a class role in the solution
�� The name State is taken from the root of the
(often stateless!) class hierarchy that
defines modal behaviour
50

The Methods for States Pattern
• Methods for States represents each state as a table
or record of method references
�� The methods referenced are on
the context object
Context
object
Current
state
Tables (e.g. struct) struct)
of
method references
Methods on the
context object
a(...) { ... ... }
b(...) { ... ... }
c(...) { ... ... }
d(...) { ... ... }
e(...) { ... ... }
51

The Collections for States Pattern
• How should state be represented for objects that
are managed collectively?
�� Partition objects into collections with respect to state,
so that state is represented by collection membership
Common operations on objects in the same state
Transition of objects
between states
Collection representing state
Managed object
52

The State of the Union
• There are many other successful recurring
solutions for expressing modal behaviour
�� And many of these are also complementary in the sense
that they can also be used together
• These patterns focus mainly on the representation
of modal state, less on the mechanics of transition
Objects for
States
Methods for
States
Collections
for States
53

Scope and Granularity
• Intent
�� Nail down the proper scope and granularity for some
common patterns, so that they do one thing well
• Content
�� Overworked and underpaid
�� Iterator reiterated
�� Bridge
�� Flyweight and friends
�� Dividing between Template Method
and Strategy
54

Overworked and Underpaid
• Some patterns just seem to be too busy solving
everyone's problems to be cohesive
�� Adapter is expressed as two fundamentally different
solutions... so isn't that two patterns?
�� Bridge seems to span more water than the Øresund resund, ,
addressing multiple problems with multiple solutions
�� Must Iterator necessarily be the design solution for all
iteration requirements?
�� Objects for States covers intent but is short on detail
�� And what is the Flyweight pattern?
55

Problem–Solution Problem Solution Multiplicity
• Some common patterns seem to identify
themselves with the solution structure
�� And therefore do not have clear problem requirements
• Other common patterns seem to identify with the
general theme of the problem
�� And therefore do not have distinct solutions
• Many common patterns appear to hide or act as
the gateway to a small community of patterns
�� Inspection reveals another level of design consideration
56

Iterator Reiterated
• GoF tries to accommodate both C++-like C++ like and
Smalltalk-style Smalltalk style iteration in one pattern
�� The external and internal variants of Iterator
�� However, most developers equate Iterator with the
external variant, and do not consider the internal one
• The problem solved, the solution structure and the
consequences are totally different
�� Hence, two quite distinct patterns —
Iterator and Enumeration Method —
not one pattern with two variations
57

The Bridge Pattern
• The metaphor of a bridge between abstraction and
internal implementation is compelling
�� But the motivation seems to be disconnected from
many of the uses and the discussion of consequences
• Bridge appears to be many things to many people
�� As in other aspects of life, not always a good thing
Bridge
Decouple an an abstraction from from its its implementation so so that that the the two two can can vary vary
independently.
58

The Problems Listed
• The original list plus recent additions...
�� Loosen permanence of implementation binding
�� Independent implementation and abstraction extension
�� Reducing compilation ripple effect
�� Data hiding in C++
�� Elimination of multiple inheritance
�� Representation sharing
�� Reduction of stack footprint
�� Exception safety in C++
59

The Solutions Offered
• The stable theme is that there is a handle–body
handle body
separation introduced into the structure
�� But handle–body handle body on its own is structure without intent
• The variations, however, are less easily fixed...
�� No class hierarchies, abstraction class hierarchy,
implementation class hierarchy, or hierarchies for both
�� The abstraction is either a handle or a proper entity
�� No sharing of representation or sharing, optionally with
reference counting
�� Optionally hide the representation class definition
60

Bridge Configuration Sketch
• This seems like a number of different patterns that
are largely unrelated in the problem solved
�� Their only common feature is a handle–body handle body separation
in the solution... which is true of most GoF patterns!
Handle
N may be 1 (exclusive) or
1..* (shared, with counting)
N
Optional
hierarchy
Body
Optional
hierarchy
61

Different Problem or Solution?
• Diversity in pattern expression is good... but there
is such a thing as too much of a good thing...
�� The pattern becomes all things to all people, each
person with their own different (incompatible) view
�� Dilutes the notion of patterns as design vocabulary
• A pattern solves a general problem with a general
but coherent solution
�� It does not solve many general problems with many
general solutions
62

The Flyweight Pattern
• What is the defining characteristic of Flyweight?
�� Is it creation?
�� Is it sharing?
�� Is it the use of extrinsic state?
�� Is it immutability?
• Is it all or some of these?
�� Or is it something else?
Flyweight
Use Use sharing to to support large numbers of of fine-grained objects efficiently.
63

Underweight or Overweight?
• It is something to do sharing, but is this a
structural or creational issue?
�� It is not classified as creational, but that is a key feature
• Are we solving all problems of sharing?
�� Or are these separate patterns?
• Is Flyweight actually a solution?
�� The intent is noble, but the solution is
uncohesive... uncohesive...
it is either many solutions
or not a solution
64

The Solutions Inside Flyweight
• Within what appears to be Flyweight there are a
number of more concrete patterns at work
�� And some that should be at work
• It appears that Flyweight is actually the wrong
cross-section cross section of the problem space
�� Immutable Value, with some variant
of Factory Method plus Pooling
would appear clearer base ingredients
65

The Immutable Value Pattern
• How can you share fine-grained fine grained objects, such as
values, without side-effect side effect problems?
�� If not designed for (or around), reference-based
reference based
semantics can undermine encapsulation, via aliasing
• Define a type whose instances are immutable
�� The internal state of the object is set at
construction
�� Value change is effected through creation
of or binding to another object
66

More Than One Factory Method
• Factory Method can be seen as a general pattern
that has specific, named variations
�� Plain Factory Method, which supports encapsulated but
not polymorphic creation
�� Class Factory Method at class level, i.e. static
�� Polymorphic Factory Method, which is the classic
Factory Method
�� Cloning Method, which is different in intent to
Prototype but may be employed by Prototype
• Plus domain-specific domain specific variations of each of these
67

The Pooling Pattern
• Can reduce creation and GC recycling costs by
explicitly pooling objects
�� Populate (or depopulate) pool on demand
�� Retain recycled pool objects
• The pool implements...
�� Factory and disposal roles
�� Pool clearing and other
management
68

The Counting Handle Pattern
• In the context of a language such as C++, a handle
object can be used to track pool object usage
�� Reference counting allows the pool to know when an
object is no longer in use, should it wish to discard it
�� In Java, weak references can be used to achieve a
similar effect
Counting Handle
Simplify the the lifetime management of of shared heap heap objects by by introducing
handle objects that that act act as as the the references to to the the heap heap object, tracking its its
usage.
69

Flyweight Reconstructed
• Flyweight is better considered a community of
patterns than an individual pattern
�� It is a connected collection of patterns that has no
obvious root pattern that can be named Flyweight
Immutable
Value
Factory
Method
Pooling
Disposal
Method
Counting
Handle
Proxy
70

The Template Method Pattern
• A pattern that captures control-flow control flow commonality
and separates it from variability of detail
�� Commonality is captured in a class and variability is
deferred to methods overridden in subclasses
• As an aside, the name of the pattern also has an
unfortunate clash with an unrelated feature of C++
Template Method
Define the the skeleton of of an an algorithm in in an an operation, deferring some steps steps
to to subclasses. Template Method lets lets subclasses redefine certain steps steps of of
an an algorithm without changing the the algorithm's structure.
71

Template Method Sketch
• Control flow is specified in superclass and the
details are filled out in the subclass
�� Can provide default
implementation in
the superclass... superclass...
�� But excessive use of
this capability makes
class hierarchies
hard to understand
and change rather
than more convenient
Algorithm
Sketch
templateMethod
hookMethod1
hookMethod2
Algorithm
Detail
hookMethod2
...
hookMethod1(...)
...
hookMethod2(...)
...
Note the use of self-
delegation, with
variation through
inheritance
72

Two Much
• Template Method seems to include too much
�� First, the solution that factors out common control flow
�� Second, the solution that chooses to delegate
responsibility for detail to subclasses
• For some developers it represents one or the other
rather than both, which can lead to confusion
�� However, both the control flow skeleton and use of
overridden methods are tightly bound to the description
of the pattern, so the pattern solution is definitely both
73

The Strategy Pattern
• Offers a delegation-based delegation based alternative to
subclassing the class that defines the algorithm
�� Often too narrowly described in terms of expressing
just a family of algorithms through an interface: related
parts of an algorithm may also be expressed
�� Some relationship between Template Method and
Strategy is alluded to but not explored in GoF
Strategy
Define a family of of algorithms, encapsulate each each one, one, and and make them them
interchangeable. Strategy lets lets the the algorithm vary vary independently from from
clients that that use use it.
it.
74

Strategy Configuration Sketches
• Applies to both inheritance and template-based
template based
approaches, where it is better known as Policy
�� Runtime versus compile-time compile time binding of the policy
usage
Client
Client
usage
Policy >
PolicySpec
strategy
Strategy
operation
PolicySpec
operation
...
strategy.operation(...)
...
...
Policy.operation(...)
...
75

A Clearer Separation
• Template Method can be seen as a compound
pattern of Method Skeleton and Hook Method
�� The common algorithm structure is expressed in the
Method Skeleton, and variation is expressed either
through Hook Methods or via a Strategy
Template
Method
Hook
Method
Method
Skeleton
Strategy
76

A Deconstructed Variation
• The idea of non-virtual non virtual public interface (NVI) has
been proposed as a guideline for C++ interfaces
• Although it looks a bit like Template Method, and
has sometimes been labelled as such, it is not
�� It is not motivated by the same
problem and has a quite distinct
solution structure
Interface
+ operation
– doOperation
Implementation
– doOperation
77

Dysfunctional Patterns
• A dysfunctional pattern is a design that recurs but
whose forces and consequences are out of balance
�� E.g. the so-called so called Getters and Setters pattern
• In this case, NVI fails to adequately offer the
benefits that are advertised as its motivation
�� Code simplification, extensibility, decoupling, thread
safety, instrumentation, assertion checking, etc
�� It has the plausible appeal of a solution, but one that is
in search of a problem — it is in need of a problem that
is not already better addressed by other patterns
78

Singleton
• Intent
�� Understand the pattern that describes an object in a
class of its own
• Content
�� Singleton
�� Global domination
�� Demotivating examples
�� Solving the solution
�� Parameterize from Above
79

The Singleton Pattern
• Singleton is both a whisky and a pattern
�� But the former is often better for design than the latter
• Half of its problems are the misconceptions
developers hold about it
�� The other half is the publicity it receives in terms of
how to apply and fix it
�� And the remaining half are in the book
Singleton
Ensure a class class only only has has one one instance, and and provide a global point of of
access to to it.
it.
80

Global Domination
• Apparently, Singleton is the most important
pattern in the book
�� Just try googling for it
�� Apparently, many 'experts' say so
• It now seems to appear — at least twice :-) : ) — in
almost every OO system
How do do you you provide global variables in in languages without global
variables? Don't. Your programs will will thank you you for for taking the the
time to to think about design instead.
Kent Kent Beck
Beck
81

What the Gang of Four Say...
• It is taught to novices, sometimes as a first pattern,
but it was never intended that way
�� And Erich has also since said that "we should never
have put it in the book"
If If you you aren't aren't an an experienced object-oriented designer, then then start start with with the the simplest simplest
and and most most common patterns: Abstract Factory, Adapter, Composite,
Decorator, Factory Factory Method, Observer, Strategy, Template Method. It's It's hard hard to to
find find an an object-oriented system system that that doesn't doesn't use use at at least least a couple couple of of these these patterns,
and and large large systems systems use use nearly nearly all all of of them. them. This This subset subset will will help help you you understand
design design patterns in in particular and and good good object-oriented design design in in general.
Gamma, Helm, Helm, Johnson and and Vlissides
82

Demotivating Examples
• No concrete example is used to illustrate the
pattern, and the cited examples are not motivating
�� Only one print spooler in a system
�� Only one file system in a system
�� Only one window manager in a system
�� Only one A/D converter in a digital filter
�� Only one company served by an accounting system
• The uniqueness constraint is either (co)incidental
( co)incidental
or not actually a constraint
83

The Simplest Class Diagram?
• There are no users
�� Perhaps this is how it should be ;-) ;
• The simplicity of the diagram is simplistic
�� Which misleads a number of developers to apply it as
an apparently simple pattern
• The pattern is also applied unnecessarily in GoF
�� For example, it is used in Objects for States to share
single instances of 'state' objects where there is no
relevant uniqueness constraint
84

Only Good Things
• Five consequences are listed for the pattern, all of
them benefits
�� What, no liabilities?
• This seems too good to be true!
�� The nature of design involves decisions, implicit or
explicit, and decisions involve trade-offs trade offs
• And in the context of Singleton, the
absence of liabilities is clearly not
quite right
85

Secondary Industries
• A whole industry in print and online seems to
have sprung up around Singleton implementation
�� How to delete a Singleton
�� How to make a Singleton thread safe
�� How to customise Singleton behaviour
�� How to exchange a Singleton (can you get a refund?)
�� How to refactor away from Singleton
• Deconstruction suggests that perhaps Singleton is
a problem, not a solution
86

Dysfunctional Alternatives
• The Monostate pattern is sometimes put forward
as an alternative to Singleton
�� Define an ordinary instance interface to class-wide class wide
state, so instances are created locally and all instances
share the same state — hence its alias, the Borg pattern
• Monostate seems to target the syntax overhead
and burden of conscience of using Singleton
�� But does not actually address any of the core issues
�� Leads to implicitly aliased value objects that can
acquire and change state automagically
87

Solving the Solution
• In most cases, instance control is a property of (a
part of) an application, not of a type
�� Therefore, the pattern's scope of
applicability is significantly smaller
than advertised
• The pattern has...
�� Missing ingredients
�� Alternative solutions
�� Scope and granularity issues
88

Requirements and Analysis
• A design that is so typically problematic or widely
misunderstood cannot be considered successful
�� Such failure is clearly the case with Singleton
• What we need from a pattern...
�� A clear motivation
�� A concrete solution that addresses a real problem
�� A solution that is consistent and complete
�� A solution that is markedly better than any alternatives
�� An honest understanding of the consequences
89

Design Principles
• High cohesion and loose coupling
�� Testability, stability, evolvability and configurability
• Program to an interface, not an instance
�� Substitutability is an important guiding principle of
decoupled design; globals are not
• Economy and necessity of solution
�� Solves the right problem sufficiently and in a way that
answers more questions than it raises
90

Granularity
• Extracting an interface gives us an Explicit
Interface to implement in the concrete Singleton
�� We can program against it and configure behind it
�� Singleton is the only creational pattern that does not
decouple through an interface
• Singleton is built on Lazy Evaluation
�� Lazy Evaluation is a pattern in its own right, addressing
forces at its own level
�� It does not attempt to deal with issues of application
intent, which is the domain of Singleton
91

Concurrency
• A great deal of design effort has been thrown at
Singletons to make them threadsafe
�� Lazy Evaluation needs careful consideration in the
presence of threads
• However, Double-Checked Double Checked Locking is highly
platform dependent
�� For instance, Java does not currently guarantee any of
the properties that allow it to work
�� Such fragility leads to unnecessary subtlety
92

Reconstruction
• A refactored Singleton...
�� Is a community of patterns that
covers the design space more
thoroughly
Explicit
�� Has clear consequences
Interface
�� Enforces a genuine creation
constraint
�� Is not sold in terms of global access as its
defining property
Singleton
Class Factory
Method
Lazy
Evaluation
Double-
Checked
Locking
93

Genuine Constraint
• A Singleton can be used where there is a genuine
constraint that there can be only one instance
�� In other words, where having more than one would
cause incorrect behaviour in the system...
�� Not just because there happens to be only one instance
in a particular configuration
• Wrapping up devices and stateful, procedural
APIs are examples that offer real motivation
�� But such uniqueness does not make them globals
94

Parameterize from Above
• We can go a step further and propose a design that
has desirable architectural consequences
�� Based on the Layers pattern and the layering metaphor
�� Complementary to Singleton, but normally replaces it
• Pass in configuration parameters and 'known'
objects rather than having them global or pulled in
�� Communicate through constructor arguments or
template parameters, as appropriate
�� E.g. the Mock Object unit testing technique, the
application of Strategy/Policy, Context Object, etc
95

Outroduction
• Intent
�� Review the opening position, draw some conclusions
and then, in the spirit of this talk's title, move on
• Content
�� Twenty-three Twenty three patterns in review
�� A process and a thing
�� Pattern communities and generative
phrases
�� Pattern languages
96

Twenty-Three Twenty Three Patterns in Review
• Yes, there is good design thinking in Gang of Four
�� But it gives insufficient coverage of the practices that
are involved in successful real-world real world OO design
• Yes, the naming of individual practices is useful
�� But scope and applicability is often unclear or too broad
• Yes, the catalogue was a good start
�� But a starting point is just that: it is only one point on
the whole line of development
97

So, What Then is a Pattern?
• A pattern considers and encapsulates a set of
conflicting design forces
• A pattern proposes a configuration to balance
these forces
�� Such a design decision has consequences
A pattern is is a piece of of literature that describes a design
problem and a general solution for for the problem in in a
particular context.
Jim Jim Coplien
Coplien
98

A Process and a Thing
• A pattern is a thing, but it's not a component
• A pattern is also a process: it is not just a static
snapshot of design or design thinking
�� A pattern must describe what to build, why and,
importantly, how
�� Each one is a highly specific mini-methodology
mini methodology
• Patterns are not rigid and automatic, and must be
considered and adapted every time
�� They inform a design rather than dictate it
99

Pattern Communities
• Patterns can be used in isolation with some degree
of success
�� Represent foci for discussion or point solutions
• However, patterns are in truth gregarious
�� They are rather fond of the company of other patterns
�� To make practical sense as a design idea,
patterns inevitably enlist other
patterns for expression
and variation
100

Generative Phrases
• Design is conversational in nature, an open-ended open ended
dialogue with a context
• In almost every case, a standalone pattern has been
decomposed, added to or connected
�� Richer, general design discussion for more specific
solutions
• This tendency is also visible in places in the Gang
of Four book, but is not made explicit
�� It appears as no more than a subplot
101

Towards Pattern Languages
• A pattern language connects patterns
�� Consequences of one pattern may generate forces that
must be resolved by another
• Pattern languages are intentional, conversational
and architectural
A pattern language is is a collection of of patterns that that build on on each each other
to to generate a system. A pattern in in isolation solves an an isolated design
problem; a pattern language builds a system. It It is is through pattern
languages that that patterns achieve their their fullest power.
Jim Jim Coplien
Coplien
102

Tales of Software Design
• A pattern is a study in design and a fragment of
design vocabulary
• It tells a "successful software engineering story"
�� Albeit a short one
• A pattern language is a framework that
expands the range and scope of the
stories than can be told
103

In Closing
• Patterns distil successful design experience
�� This is the message; it should not be confused with or
restricted to the medium
• There is more to both OO design and patterns than
is achieved or intended by the Gang of Four
�� It was a good start, but it is a historical subset of the
patterns we need to know for effective design
There are more things in in heaven and earth, Horatio,
than are dreamt of of in in your philosophy. William Shakespeare
104

Bibliography
GoF
Design Patterns: Elements of Reusable Object-Oriented Object Oriented Software, Software,
Erich Gamma, Richard
Helm, Ralph Johnson and John Vlissides, Vlissides,
Addison-Wesley, Addison Wesley, 1995
Pattern Hatching: Design Patterns Applied, Applied,
John Vlissides, Vlissides,
Addison-Wesley, Addison Wesley, 1998
The Design Patterns Smalltalk Companion, Companion,
Sherman R Alpert, Kyle Brown and Bobby
Woolf, Woolf,
Addison-Wesley, Addison Wesley, 1998
POSA
Pattern-Oriented Pattern Oriented Software Architecture, Volume 1: A System of Patterns, Patterns,
Frank Buschmann,
Regine Meunier, Meunier,
Hans Rohnert, Peter Sommerlad and Michael Stal, Stal,
Wiley, 1996
Pattern-Oriented Pattern Oriented Software Architecture, Volume 2: Patterns for Concurrent Concurrent
and Networked
Objects, Objects,
Douglas Schmidt, Michael Stal, Stal,
Hans Rohnert and Frank Buschmann, Wiley,
2000
Pattern-Oriented Pattern Oriented Software Architecture, Volume 3: Patterns for Resource Management,
Management,
Michael Kircher and Prashant Jain, Wiley, to be published 2004
105

Bibliography
Alexander
A Pattern Language: Towns, Buildings, Construction, Construction,
Christopher Alexander, Sara Ishikawa
and Murray Silverstein, Oxford University Press, 1977
The Timeless Way of Building, Building,
Christopher Alexander, Oxford University Press, 1979
Beck
"Using Pattern Languages for Object-Oriented Object Oriented Programs", Kent Beck and Ward
Cunningham, OOPSLA, OOPSLA,
1987
Smalltalk Best Practice Patterns, Patterns,
Kent Beck, Prentice Hall, 1997
Test-Driven Test Driven Development: By Example, Example,
Kent Beck, Addison-Wesley, Addison Wesley, 2003
Coplien
Advanced C++ Programming Styles and Idioms, Idioms,
James O Coplien, Coplien,
Addison-Wesley, Addison Wesley, 1992
Software Patterns, Patterns,
James O Coplien, Coplien,
SIGS, 1996
Multi-Paradigm Multi Paradigm Design for C++, C++ , James O Coplien, Coplien,
Addison-Wesley, Addison Wesley, 1999
106

Bibliography
Henney
"Collections for States", Kevlin Henney, EuroPLoP, EuroPLoP,
1999
"A Tale of Two Patterns", Kevlin Henney, Java Report, Report,
December 2000
"C++ Patterns: Reference Accounting", Kevlin Henney, EuroPLoP, EuroPLoP,
2001
"A Tale of Three Patterns", Kevlin Henney, Java Report, Report,
October 2001
"Methods for States", Kevlin Henney, VikingPLoP, VikingPLoP,
2002
"Explicit Interface and Object Manager", Frank Buschmann and Kevlin Kevlin
Henney, EuroPLoP, EuroPLoP,
2003
"The Good, the Bad, and the Koyaanisqatsi", Koyaanisqatsi",
Kevlin Henney, VikingPLoP, VikingPLoP,
2003
"Factory and Disposal Methods", Kevlin Henney, VikingPLoP, VikingPLoP,
2003
107

Bibliography
Others
Core J2EE Patterns, Patterns,
2 nd edition, Deepak Alur, Alur,
John Crupi and Dan Malks, Malks,
Prentice Hall,
2003
Modern C++ Design, Design,
Andrei Alexandrescu, Alexandrescu,
Addison-Wesley, Addison Wesley, 2001
Object-Oriented Object Oriented Analysis and Design with Applications, Applications,
2 nd edition, Grady Booch, Booch,
Benjamin/Cummings, 1994
Troublesome Words, Words,
3 rd edition, Bill Bryson, 2001
Generative Programming, Programming,
Krzysztof Czarnecki and Ulrich W Eisenecker, Eisenecker,
Addison-Wesley,
Addison Wesley,
2000
"Endo-Testing: "Endo Testing: Unit Testing with Mock Objects", Tim Mackinnon, Steve Freeman Freeman
and
Philip Craig, XP, XP,
2000
Design Patterns for Object-Oriented Object Oriented Software Development, Development,
Wolfgang Pree, Pree,
Addison- Addison
Wesley, 1995
The Design and Evolution of C++, C++ , Bjarne Stroustrup, Stroustrup,
Addison-Wesley, Addison Wesley, 1994
Taligent's Guide to Designing Programs, Programs,
Addison-Wesley, Addison Wesley, 1994
108