This document provides an introduction to design patterns. It begins by explaining what design patterns are, their benefits, and common elements of design patterns like name, problem, solution, and consequences. It then discusses different types of design patterns classified by purpose (creational, structural, behavioral) and scope (class, object). An example of applying the strategy pattern to a duck simulation is used to illustrate how patterns can solve common object-oriented design problems by separating variable aspects from those that remain the same. The document advocates programming to interfaces rather than implementations to avoid tight coupling and allow independent extension of behavior.

1. DESIGN PATTERNS
Introduction

2. COURSE DESCRIPTION
 Traditionally, OO designers have developed their own
private "catalogs" of solutions to recurring design
problems.
 More recently, advocates of design patterns have
created public repositories of patterns that more
formally
 Identify these recurring design problems
 Document possible solutions to these problems through the
general arrangement and composition of objects and
classes
 Discuss the advantages and disadvantages of the various
solutions and
 Provide implementation examples. This course will
introduce the student to the concept of design patterns,
examine several patterns in detail, apply these patterns to
specific problems, and point the student to design pattern
resources. 2

3. RECOMMENDED TEXTBOOKS
 Recommended Text
 Design Patterns: Elements of Reusable Object-
Oriented Software (1995) by Gamma; ISBN 0-201-
63361-2 published by Pearson Education
 Additional Reading
 Head First Design Patterns (2004) by Freeman;
ISBN 0-596-00712-4 published by O'Reilly and Assoc.
3

4. MARKS DISTRIBUTION
 6-8 Quizzes: 15%
 2 Assignments: 25%
 Mid term Exam:30%
 Final Exam: 30%
4

5. OUTLINE
 Introduction to Design Patterns
 Describing Design Patterns
 The Design Patterns Catalog
 How to Select and Use a Design Pattern
 Creational Patterns
 Abstract Factory, Builder, Singleton etc.
 Structural Patterns
 Adapter, Bridge, Composite etc.
 Behavioral Patterns
 Command, Interpreter, Observer, Strategy etc.
5

6. WHAT’S A GOOD OBJECT ORIENTED
DESIGN
 Design should be SPECIFIC to the problem at
hand
AND
 Also be GENERIC enough to address future
problems and requirements
 So the design should be REUSABLE
 Expert designers REUSE successful designs
 Consequently REUSABLE designs are recurring
PATTERNS of classes and objects in OO Systems
6

7. REUSABILITY EXAMPLE
 Novelists & Playwrights seldom write from
scratch
INSTEAD
 Follow PATTERNS like ‘Tragically flawed Hero’
(Macbeth, Hamlet) or ‘The Romantic Novel’
7

8. WHAT IS A DESIGN PATTERN
 “A proven solution to a common problem in a specified
context.”
 Example: We can light a candle if light goes out at night
 Christopher Alexander (Civil Engineer) in 1977 wrote
 “A pattern describes a problem which occurs over and over
again in our environment, and then describes the core of
the solution to that problem, in such a way that you can
use this solution a million times over, without ever doing it
the same way twice”
 The “gang of four” (GoF)
 In 1995, the principles that Alexander established were applied
to software design and architecture. The result was the book:
 “Design Patterns: Elements of Reusable Object-Oriented
Software” by Erich Gamma, Richard Helm, Ralph Johnson, and
John Vlissides.
8

9. WHY LEARN DESIGN PATTERNS
 They make it easier to reuse successful designs
and architectures
 They can make documentation and maintenance
of the systems easier
 Design Patterns help a designer design “right”
faster
 They provide a vocabulary that can be used
amongst software developers.
 Enable us to discuss low-level implementation in
a high-level, abstract manner.
 Help in extendibility and avoiding solution
redesign
9

10. ELEMENTS OF A DESIGN PATTERN
 Pattern Name
 Is a handle to describe design problem & solution
 Problem
 Describes when a Pattern is to be applied
 Solution
 General arrangement of elements to solve a problem
 Consequences
 Results and Tradeoffs of applying a Pattern
 Tradeoffs can be space, time, language etc.
10

11. DESCRIBING A DESIGN PATTERN
 Pattern Name & Classification – Conveys the
essence of the pattern concisely
 Intent – What design issue the pattern addresses
 Also Known As – Other well known names for
this pattern
 Motivation – A scenario illustrating a design
problem and how its being solved by the pattern
 Applicability – Known situations where the
pattern can be applied
 Structure – OMT (Object Modeling ) based
graphic representation of the classes in the pattern
 Participants – Classes and objects in the pattern
with their responsibilities
11

12. DESCRIBING A DESIGN PATTERN
CONT’D
 Collaborations – How the participants
collaborate to carry out their responsibilities
 Consequences – What are the results and
tradeoffs of using the pattern
 Implementation – Hints on implementation of
the pattern like language dependency
 Sample Code – Sample code
 Known Uses – Examples
 Related Patterns – Other patterns closely
related with the pattern under consideration
12

13. NOT A DESIGN PATTERN
 Linked Lists
 Hash Tables
 Domain Specific designs for entire application or
subsystem
 A code solution ready for copy-and-paste
 Programming language features
 The same every time you see them
13

14. MVC PATTERN
 The main purpose of using MVC pattern is to decouple
the GUI from the Data. It also
 gives the ability to provide multiple views for the same
Data.
 MVC pattern separates views and models by
establishing a subscribe/notify protocol amongst them
 Application of MVC pattern has benefits like
 Classes defining application data and presentation can be
reused.
 Change in one view automatically reflected in other views.
Also, change in the application data is reflected in all views.
 Defines one-to-many dependency amongst objects so that when
one object changes its state, all its dependents are notified 14

15. MVC PATTERN CONT’D
A=10%
B=40%
C=30%
D=20%
Application data
A
B
C
D
A DCB
Relative Percentages
Y 10 40 30 20
X 15 35 35 15
Z 10 40 30 20
A B C D
Change notification
Requests, modifications
Model
15

16. MVC PATTERN CONT’D
 Model: - This section is specially for maintaining data. It is
actually where your business logic, querying database, database
connection etc. is actually implemented.
 Views: - Displaying all or some portion of data, or probably
different view of data. View is responsible for look and feel,
Sorting, formatting etc.
 Controller: - They are event handling section which affects
either the model or the view. Controller responds to the mouse or
keyboard input to command Model and View to change.
Controllers are associated with views. User interaction triggers
the events to change the Model, which in turn calls some methods
of Model to update its state to notify other registered Views to
refresh their display.
16

17. DESIGN PATTERNS
CLASSIFICATION
 According to the GOF, the design patterns can be
classified in two ways
 According to the PURPOSE
 According to the SCOPE
 PURPOSE of Design Patterns reflect what
actually they do
 SCOPE of Design Patterns reflect whether they
apply primarily to Classes or Objects.
17

18. PURPOSE BASED DESIGN
PATTERNS CLASSIFICATION
 Creational – Concerned with the purpose of
object creation or class instantiation
 Structural – Deal with composition of classes and
objects
 Behavioral – Characterize the ways in which
classes and objects interact and distribute
resposibility.
18

19. SCOPE BASED DESIGN PATTERNS
CLASSIFICATION
 Class Patterns deals with the relationships
amongst the classes and their subclasses
 These relationships are established through
INHERITANCE, so they are static – fixed at
compile time
 Object Patterns deals with object relationships
which can be changed at runtime or are dynamic
 Note that most patterns are object patterns
19

20. PURPOSE & SCOPE BASED DESIGN
PATTERNS CLASSIFICATION
 Creational Class patterns defer some part of
object creation to subclasses where as creational
object patterns defer it to another object.
 Structural class patterns use inheritance to
compose classes, while structural object patterns
describe ways to assemble objects.
 Behavioral class patterns use inheritance to
describe algorithms and flow of control, whereas
the behavioral object patterns describe how a
group of objects cooperate to perform a task
20

21. DESIGN PATTERNS
CLASSIFICATION
Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter(Class) Interpreter
Template Method
Object Abstract Factory
Builder
Prototype
Singleton
Adapter(Object)
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
21

22. HOW DESIGN PATTERNS SOLVE
DESIGN PROBLEMS
 Finding appropriate objects
 The hard part about OOD is decomposing a system into
objects
 They help to introduce an abstraction for treating
objects uniformly that doesn’t have a physical
counterpart
 They help to identify less obvious abstractions and
objects that can capture them
 These objects are seldom identified in a design earlier
and are discovered while making the design reusable
and more flexible
 Determining the object Granularity
 They help in specifying how to represent complete
subsystems as objects
 They help you in decomposing objects into smaller
objects 22

23. HOW DESIGN PATTERNS SOLVE
DESIGN PROBLEMS
 Specifying Object Interfaces
 Help you in defining interfaces and the kinds of data
that get sent across them
 Might also tell what NOT to put into an interface
 Also specify relationships across interfaces
 Designing for Change
 Help you to avoid dependence on specific operations
 Help you to avoid dependence on hardware and
software platforms
 Help to avoid algorithmic dependencies
23

24. PATTERNS AND ALGORITHMS
 Algorithms and data structures generally solve
more fine-grained computational problems like
sorting and searching.
 Patterns are typically concerned with broader
architectural issues that have larger-scale
effects.
24

25. PATTERNS AND FRAMEWORKS
 A software framework is a set of cooperating
classes that make up a reusable design for a
specific class of software [Deu89,JF88]
 A framework will dictate overall structure,
partitioning of classes and objects, how the
classes or objects collaborate
 A framework is usually not a complete
application: it often lacks the necessary
application-specific functionality.
 Examples
 Framework for building compiler for different
languages and machines.
 For building financial modeling applications 25

26. PATTERNS AND FRAMEWORKS
 Design patterns may be employed both in the design and
the documentation of a framework. A single framework
typically encompasses several design patterns. A
framework can be viewed as the implementation of a
system of design patterns.
 Frameworks and design patterns are distinct: a framework
is executable software, design patterns represent
knowledge and experience about software. Frameworks are
of a physical nature, patterns are of a logical nature:
frameworks are the physical realization of one or more
software pattern solutions; patterns are the instructions
for how to implement those solutions.
 Major differences:
 Design patterns are more abstract than frameworks.
 Design patterns are smaller architectural elements than
frameworks.
 Design patterns are less specialized than frameworks. 26

27. AN EXAMPLE CASE
 Goals
 Learn how to exploit and gain experience of others
 Examine the benefits of design pattern
 Learn one specific pattern: Strategy pattern
27

28. SIMPLE SIMULATION OF DUCK
BEHAVIOR
Duck
quack()
swim()
display()
// other duck methods
MallardDuck
display()
// looks like mallard
RedheadDuck
display()
// looks like redhead
Other duck
types
28

29. SIMPLE SIMULATION OF DUCK
BEHAVIOR
 All ducks Quack and Swim the super class
DUCK takes care of the implementation code.
But
 Each duck subtype is responsible for
implementing its own Display method as each
duck looks different
 In the super class the Display method is abstract.
29

30. WHAT IF WE WANT TO SIMULATE
FLYING DUCKS?
Duck
quack()
swim()
display()
fly()
// other duck methods
MallardDuck
display()
// looks like mallard
RedheadDuck
display()
// looks like redhead
Other duck
types
30

31. TRADEOFFS IN USE OF
INHERITANCE AND MAINTENANCE
Duck
quack()
swim()
display()
fly()
// other duck methods
MallardDuck
display()
// looks like mallard
RubberDuck
quack()
//overridden to squeak
display()
// looks like rubberduck
fly()
// override to do nothing
RedheadDuck
display()
// looks like redhead
One could override the
fly method to the appropriate
thing – just as the quack
method below.
31

32. EXAMPLE COMPLICATED: ADD A
WOODEN DECOY DUCKS TO THE
MIX
DecoyDuck
quack(){
// override to do nothing
}
display()
// display decoy duck
fly (){
//override to do nothing
}
Inheritance is not always the right
answer. Every new class that inherits
unwanted behavior needs to be
overridden.
How about using interfaces instead?
32

33. USING INTERFACES IN OUR
EXAMPLE
 We can take Fly() out of the superclasses
 We make an interface iFlyable containing the
Fly() method. That way the ducks supposed to fly
can implement that interface and have a Fly()
method
 Same solution can be implemented for Quack(),
we can make interface iQuackable containing the
Quack() method
33

34. DUCK SIMULATION RECAST USING
INTERFACES
Duck
swim()
display()
// other duck methods
MallardDuck
display()
fly()
quack()
Quackable
quack()
Flyable
fly()
RedheadDuck
display()
fly()
quack()
RubberDuck
display()
quack()
DecoyDuck
display()
Interfaces
34

35. PROS & CONS
 Not all inherited methods make sense for all
subclasses – hence inheritance is not the right
answer
 But by defining interfaces, every class that needs
to support that interface needs to implement that
functionality… destroys code reuse and creates a
maintenance issue.
 So if you want to change the behavior defined by
interfaces, every class that implements that
behavior may potentially be impacted
AND
 Change is constant in Software Development
 Overtime an application must change and grow
or it will die…
35

36. DESIGN PRINCIPLES TO THE
RESCUE
 Identify the aspects of your application that vary
and separate them from what stays the same.
OR
Take the parts that vary and encapsulate them,
so that later you can alter or extend the parts
that vary without affecting those that don’t.
 Program to an interface, not to an
implementation (Discussed Later)
36

37. CHANGE IN DUCK CLASSES
ACCORDING TO THE DESIGN
PRINCIPLE
 As far as we can tell other than the problems
with Fly() and Quack() the Duck Class is fine.
 Now to separate “the parts that change from
those which remain the same”, we can create two
sets of classes apart from the Duck Class.
 One set can represent the Quacking behaviors
e.g. a class implements quacking, another
implements squeaking etc.
 Similar is the case with Flying behaviors
37

38. 38

39. DESIGN PRINCIPLE
 Program to an interface, not to an implementation
 We will use interfaces to represent each behavior
 Each Implementation of behavior will implement
these interfaces
 So the duck classes won’t implement these interfaces
instead the set of classes for behavior would
implement them.
 With our new design the duck classes would USE a
behavior represented by an interface. OR
 The actual implementation won’t be locked in the
duck classes. 39

40. IMPLEMENTING DUCK BEHAVIORS -
REVISITED
FlyWithWings
fly(){
// implements duck
flying
}
<<interface>>
FlyBehavior
fly()
<<interface>>
QuackBehavior
quack()
Quack
quack(){
// implements duck
quacking
}
FlyNoWay
fly(){
// do nothing –
Can’t fly
}
Squeak
quack(){
// implements duck
squeak
}
MuteQuack
quack(){
// do nothing –
Can’t quack
}
Key now is that Duck class will delegate
its flying and quacking behavior instead of
implementing these itself
40

41. IN THE DUCK SIMULATION
CONTEXT…
41
Duck
FlyBehavior: flyBehavior
QuackBehavior: quackBehavior
performQuack()
swim()
display()
performFly()
//other duck-like methods
Duck
Behaviors
41

42. DUCK SIMULATION RECAST USING
THE NEW APPROACH
42
MallardDuck
display()
RedHeadDuck
display()
RubberDuck
display()
DecoyDuck
display()
Duck
FlyBehavior: flyBehavior
QuackBehavior: quackBehavior
performQuack()
performFly()
setFlyBehavior()
setQuackBehavior()
swim()
display()
<<interface>>
FlyBehavior
fly()
FlyWithWings
fly()
// implements duck
flying
FlyNoWay
fly()
// do nothing –
Can’t fly
<<interface>>
QuackBehavior
quack()
Quack
quack()
// implements
duck
quacking
Squeak
quack()
// implements
squeak
Mutequack
quack()
// do nothing

43. DESIGN PRINCIPLE
 Favor composition over inheritance
 HAS-A can be better than IS-A
 Composition lets you encapsulate a family of
algorithms into their own set of classes.
 Allows changing behavior at run time
43

44. THE STRATEGY PATTERN
44
The Strategy Pattern defines a family of algorithms,
Encapsulates each one, and makes them
interchangeable. Strategy lets the algorithm vary
independently from clients that use it.