An discussion about choosing design patterns in object orientation. Suitable for intermediate to advanced computing students and those studying software engineering.

1. Choosing a
Design Pattern
Michael Heron

2. Introduction
 Knowing what the patterns are and what
they are for is part of the battle.
 Knowing when and where they should be
applied is the other.
 In this lecture we are going to discuss the
ways in which you can determine the
usefulness of a pattern.
 And where they are not useful

3. Key Points
 Design patterns are generalized.
 They must be adapted to context
 Design patterns are a codified form of
developer experience.
 They represent good solutions, not necessarily
the best solutions.
 Design patterns are not always appropriate to
be applied to a given problem.
 It’s as important to know when not to use a
pattern.

4. Analyzing a Problem
 Given a particular scenario, how can you
tell if a pattern is called for?
 Consider your three families of patterns.
 Creational
 Behavioural
 Structural.
 Analyse the scenario for the existence of
terms relating to any of these three.

5. Analyzing A Problem
 The biggest skill in analyzing a scenario is
appreciation of implications.
 Put yourself in the shoes of someone writing the
program.
 What problems are you going to run into?
 This requires not only an understanding of the
scenario, but also of the nature of program
design.
 You need to know your stuff, you can’t fake this.

6. Analyzing A Problem
 Experience is the greatest predictor of future
problems.
 Call on your own experience in writing programs
to effectively analyze a scenario.
 The only way to really learn is to make mistakes –
that’s not new age mumbo jumbo, it’s the truth.
 Safe to work on the assumption that unless
great care is taken with a design, it will have
problems.
 All designs do – programming is an eternal
trade-off between competing goals.

7. Analyzing A Problem
 There is also no shortcut for working out
the implications.
 You just need to think your way through it.
 Every scenario is unique, but programming
is all about recognizing patterns.
 Compile a list of the features you know of.
 Follow them through to the logical
conclusions.
 Identify possible implications from those.

8. Example Scenario - 1
 Mega Games Corp are creating an
online role playing game. The game
consists of twenty character races, and a
selection of twenty classes for each.
Players can select the combination of the
two, and choose between three hundred
weapons, five hundred magic spells, and
six hundred pieces of armour.
 What’s the focus here?
 What are the implications?

9. Example Scenario - 2
 Picture Perfect Software Inc are
developing a new graphics package
based on the principle of potato shapes.
Users can select from a range of
preconfigured shapes and ‘stamp’ them
in paint before stamping them on the
document. Users then get to move and
recolour the pictures as needed.
 What’s the focus here?
 What are the implications?

10. From Implications To Strategy
 Knowing what the implications are allows you to map
the scenario to your available patterns.
 All patterns are designed to fill a certain role.
 Consider the patterns you have been presented.
 What is their role? What process are they designed to
manage?
 Does the analysis of the program implications
suggest that a specific pattern will be relevant.
 Note, relevant – don’t worry about whether or not it’s a
good idea yet.
 Do this for each pattern you know.
 If you don’t understand the pattern, make the effort to
do so.

11. Candidate Patterns
 Going through the patterns will give you a list
of relevant patterns to assess.
 They’re not all going to be winners.
 Consider what the impact would be of
applying a pattern.
 What are the consequences of each pattern?
 Will it improve maintainability?
 Does it improve efficiency?
 Does it open up new functionality?
 Importantly, does it solve any problems you
have identified?

12. Identify Variability
 Every program has parts of the program
that are static and parts that will change
according to circumstances.
 Identifying that variability is a key to unlock
which patterns are genuinely useful.
 Which of the moving parts in the program
are going to cause an issue?
 Inappropriate handling of variability leads
to design issues down the line.

13. Cost of Implementation
 There is a cost to implementing any given
design pattern.
 Often leads to additional complexity.
 Often leads to over-engineering
 Most patterns based on a trade-off
 Consider what the impact will be if you
implement a pattern.
 The cost of implementation may outweigh
any benefits.

14. Finally
 Having identified which design patterns are
suitable:
 Relevant
 Beneficial
 Net gain in application
 You then take this smaller pool and work out
which of these are going to be implemented.
 If any.
 Does the implementation of one design
pattern open up new implications for the
implementation of another?

15. This Is Hard…
 This is hard to do from a specification.
 If it wasn’t, people wouldn’t make so many
mistakes when designing systems!
 It’s a hugely important skill though.
 One you can practice.
 It sits between ‘knowing’ and ‘doing’.
 You need to be able to reasonably do both
to effectively analyze.

16. Refactoring
 The biggest impact well selected patterns
have is on the reduction in the need for
refactoring.
 It’s an unavoidable need, but can be
managed.
 Refactoring is the process whereby we rewrite
code the way we would have written it
before, if we weren’t operating under limits.
 Time Constraints
 Benefit of Hindsight

17. Design Patterns and
Refactoring
 Design patterns are what emerge from
successive refactoring.
 They converge on a general and almost
universally applicable solution to a given
problem.
 Adopting a design pattern early saves
you from having to adopt it later.
 Consciously or not.
 After a while, experience tends to teach you
to code in this way anyway.

18. Deep Smarts
 Some things you just can’t teach.
 They are learned only as a result of the crushing
grind of life.
 Swap and Leonard (who coined the term) put the
time needed at at least ten years.
 Some writers have termed this experience based
knowledge as deep smarts.
 A big goal of knowledge management is
cataloguing and translating as much of these
deep smarts as possible.
 Design patterns, for software engineering,
represent a library of deep smarts.

19. Where Next?
 Even though we’ve done five lectures on this topic,
we’ve only scratched the surface.
 Design patterns are rich and supported by an extensive
literature.
 The seminal book on the topic is called Design
Patterns and is authored by the ‘Gang of Four’
 Erich Gamma
 Richard Helm
 Ralph Johnson
 John Vlissides
 Students are heartily recommended to check it out.
 It covers these patterns (and more) in much more depth.

20. Summary
 Picking a design pattern is a complex task.
 Involving a mixture of skills.
 There is a process you can follow to help in
this.
 But it doesn’t do it for you.
 Thinking through the implications of scenarios
that are presented is something that comes
easier with practice and experience.
 As you build your deep smarts.