Introduce some design patterns in the book of GoF,

1. Design Patterns:
Elements of Reusable Object-Oriented Software
(Part 1)
Tom Chen

2. Overview
● Introduction
● What is Design Pattern?
● Organizing Design Patterns
● How to Select a Design Pattern?
● Design Patterns Part 1
● Creational: Factory, Abstract Factory, Singleton
● Structual: Bridge, Decorator
● Behavioral: Interpreter, Visitor

3. What is Design Pattern?
● "Each 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"

4. What is Design Pattern?
Four Essential Elements
● Pattern name
● A handle used to describe a design problem, its
solutions, and consequences in a word or two
● Problem
● When to apply the pattern.
● Solution
● The elements that make up the design, their
relationships, responsibilities, and collaborations
● Consequences
● The results and trade-offs of applying the pattern

5. Priciples of Design Patterns
● Program to an interface, not an implementation.
● Polymorphism
● Favor object composition over class
inheritance.
● Delegation

6. Organizing Design Patterns
● Creational Patterns
● Abstract the instantiation process
● Structural Patterns
● How classes and objects are composed to form
larger structures
● Behavioral Patterns
● Describe algorithms and the assignment of
responsibilities between objects
– Not just patterns of objects or classes but also the
patterns of communication between them

7. Organizing Design Patterns c.1

8. Creational Patterns
Factory Method
● Intent
● Define an interface for creating an object, but let
subclasses decide which class to instantiate.
● Motivation
● A framework for applications that can present
multiple documents to user
● Both classes of application and document are
abstract
– subclass them to realize their application-specific
implementations

9. Creational Patterns
Factory Method
Application doesn't know which subclass
to instantiate.
CreateDocument() is the factory method!

10. Creational Patterns
Factory Method
● Applicability
● A class can't anticipate the class of objects it must
create
● A class wants its subclasses to specify the objects it
creates
● Classes delegate responsibility to one of several
helper subclasses, and you want to localize the
knowledge of which helper subclass is the delegate.

11. Factory Method
Structure

12. Factory Method
Sample Code

13. Factory Method
Sample Code c.1

14. Factory Method
Sample Code c.2

15. Factory Method
Consequences
● Eliminate the need to bind application-specific
classes into your code
● Potential Disadv. : clients might have to
subclass the Creator class just to create a
particular ConcreteProduct object

16. Creational Patterns
Abstract Factory
● Intent
● Provide an interface for creating families of related
or dependent objects without specifying their
concrete classes.
● Motivation
● A UI toolkit that supports multiple look-and-feel
standards
● To be portable, should not hard-code widgets for a
particular look and feel

17. Creational Patterns
Abstract Factory
This is the Abstract Factory!

18. Abstract Factory
Applicability
● A system should be independent of how its
products are created, composed, and
represented
● A system should be configured with one of
multiple families of products.
● A family of related product objects is designed
to be used together
● Only want to reveal the interface of a class
library of products, not the implementations

19. Abstract Factory
Structure

20. Abstract Factory
Sample Code
New interface! An abstract factory.
Factory Methods are defined!

21. Pass in abstract factory.
Create objects with the factory
Usage of the new interface:

22. Abstract Factory
Consequences
● Isolates concrete classes
● Makes exchanging product families easy
● Promotes consistency among products
● Application use objects from only one family at a
time
● Difficult to support new kinds of products
● Change the AbstractFactory class and all of its
subclasses

23. Creational Patterns
Singleton
● Intent
● Ensure a class only has one instance, and provide
a global point of access to it.
● Motivation
● Important for some classes to have exactly one
instance
– Only one printer spooler, one file system, one window
manager...
● Solution: make the class itself responsible for
keeping track of its sole instance
– Ensure that no other instance can be created
– Provide a way to access the instance

24. Singleton
Applicability
● Must be exactly one instance of a class and
must be accessible to clients from a well-known
access point
● When the sole instance should be extensible by
subclassing, and clients should be able to use
an extended instance without modifying their
code

25. Singleton
Structure

26. Singleton
Sample Code

28. Singleton
Consequences
● Controlled access to sole instance
● Reduced name space
● An improvement over global variables
● Permits refinement of operations and
representation
● By subclassing
● Permits a variable number of instances
● More flexible than class operations (Static
member functions)

29. Structural Patterns
Bridge
● Intent
● Decouple an abstraction from its implementation so
that the two can vary independently.
● Motivation
● An abstract class defines the interface and concrete
subclasses implement it in different ways.
– Not always flexible enough
● Inheritance binds an implementation to the
abstraction permanently
– Difficult to modify, extend, and reuse abstractions and
implementations independently

30. Bridge
Motivation c.1
● Case: Implement a portable Window abstract
● Work on both XWindow and IBM's Presentation
Manager(PM)

31. Bridge
Motivation c.2

32. Bridge
Applicability
● Avoid permanent binding between abstraction
and implementation
● EX: Select or switch implementation at run-time
● Both the abstractions and their implementations
should be extensible by subclassing
● Changes in the implementation of an
abstraction should have no impact on clients

33. Bridge
Structure

34. Bridge
Sample Code

35. Bridge
Sample Code c.1

36. Bridge
Consequences
● Decoupling interface and implementation
● Even possible for an object to change
implementation at run-time
● Eliminate compile-time dependencies on the
implementation
● Improved extensibility
● Extend the Abstraction and Implementor hierarchies
independently
● Hiding implementation details from clients

37. Structural Patterns
Decorator
● Intent
● Attach additional responsibilities to an object
dynamically. Decorators provide a flexible
alternative to subclassing for extending
functionality.
● Motivation
● Add responsibilities to individual objects, not to an
entire class
– EX: Add properties like borders or behaviors like scrolling
to any UI component
● Inheritance is inflexible

38. Structural Patterns
Decorator

39. Structural Patterns
Decorator
DrawScrollbar()
Draw()
Draw()
Draw()
DrawBorder()

40. Decorator
Applicability
● Add responsibilities to individual objects
dynamically and transparently
● For responsibilities that can be withdrawn
● When extension by subclassing is impractical
● Produce an explosion of subclasses
● Class definition may be hidden or unavailable for
subclassing

41. Decorator
Structure

42. Decorator
Sample Code

43. Decorator
Sample Code c.1

44. Decorator
Consequences
● More flexibility than static inheritance
● Responsibilities can be added and removed at run-
time
● Avoid feature-laden classes high up in the
hierarchy
● Inheritance requires creating a new class for each
additional responsibility
● A decorator and its component aren't identical
● Lots of little objects
● Easy to customize but can be hard to learn and
debug

45. Behavioral Patterns
Visitor
● Intent
● Represent an operation to be performed on the
elements of an object structure
● Define a new operation without changing the
classes of the elements on which it operates
● Motivation
● 2D CAD System: Simple geometries compose a
model
● Basic functions
– Save model to file, drawing, dragging, scale ...

46. Visitor
Motivation
Difficult to extend the ability of Shape!

47. Visitor
Motivation c.1
Key: Double Dispatch!

48. Visitor
Applicability
● Perform operations on object structure
containig many classes of objects with differing
interfaces
● Avoid polluting classes with distinct and
unrelated operations
● Visitor keep related operations together
● Classes defining object structure rarely change,
but often define new operations
● Change class need redefining interface to all
visitors

49. Visitor
Structure

50. Visitor
Structure c.1

51. Visitor
Sample Code

52. Visitor
Sample Code c.1

53. Visitor
Consequences
● Visitor makes adding new operations easy
● Visitor gathers related operations and
separates unrelated ones
● Adding new ConcreteElement classes is hard
● Corresponding implementation in every
ConcreteVisitor class

54. Visitor
Consequences c.1
● Visiting across class hierarchies
● Iterator works for classes of the same parent
● Visitor works for classes of different parent
● Accumulating state while visiting elements
● Breaking encapsulation
● Must provide public operations that access an
element's internal state

55. Behavioral Patterns
Interpreter
● Intent
● Given a language, define a representation for its
grammar along with an interpreter using the
representation to interpret sentences in the
language
● Motivation
● Search for strings matching a pattern decribed by
Regular Expression
● Search algorithms could interpret a regular
expression rather than building custom algorithm

56. Interpreter
Motivation c.1
● Suppose the following grammar defines the
regular expressions

57. Interpreter
Motivation c.2
Context

58. Interpreter
Motivation c.3
● raining & (dogs | cats) *
EX: Context = It is raining cats and dogs.

59. Interpreter
Applicability
● Grammar is simple
● For complex grammars, the class hierarchy for the
grammar becomes large and unmanageable
● Efficiency is not a critical concern

60. Interpreter
Structure

61. Interpreter
Consequences
● Easy to change and extend the grammar
● Implementing the grammar is easy, too
● Complex grammars are hard to maintain.
● Adding new ways to interpret expressions
(Easier)
● EX: Support pretty printing or type-checking an
expression by defining a new operation
– Use Visitor to avoid changing grammar classes