Design patterns

1
Design patterns

• A design pattern is a way of reusing abstract
  knowledge about a problem and its solution
• Patterns are devices that allow programs to share
  knowledge about their design
• A pattern is a description of the problem and the
  essence of its solution
• Documenting patterns is one way to reuse and
  share the information about how it is best to
  solve a specific design problem
• A pattern should be sufficiently abstract to be
  reused in different settings
• Patterns often rely on object characteristics
  such as inheritance and polymorphism

2
History of Design Patterns

• Architect Christopher Alexander
• A Pattern Language (1977)
• A Timeless Way of Building (1979)
• Gang of four
• Erich Gamma
• Richard Helm
• Ralph Johnson
• John Vlissides
• Design Patterns Elements of Reusable
  Object-Oriented Software (1995)
• Many since
• Conferences, symposia, books

3
Pattern elements

• Name
• A meaningful pattern identifier
• Problem description
• Solution description
• Not a concrete design but a template for a design
  solution that can be instantiated in different
  ways
• Consequences
• The results and trade-offs of applying the pattern

4
Types of Patterns

• Creational
• Abstract Factory
• Structural
• Adapter
• Bridge
• Façade
• Proxy
• Behavioral
• Observer
• Mediator

5
Patterns by ExampleMultiple displays enabled by
Observer
6
The Observer pattern

• Name
• Observer
• Description
• Separates the display of object state from the
  object itself
• Problem description
• Used when multiple displays of state are needed
• Solution description
• See slide with UML description
• Consequences
• Optimisations to enhance display performance are
  impractical

7
The Observer pattern
observerState subject ? getState()
8
The Mediator Pattern

• Description
• Define an object that encapsulates how a set of
  objects interact
• Mediator promotes loose coupling by keeping
  objects from referring to each other explicitly
• It lets you vary their interaction independently
• Applicability
• Complex interaction exists
• You do not want to bury the interaction in the
  objects
• Distributed behavior should be customizable
  without a lot of subclassing
• Consequences
• Limits subclassing
• Decouples colleagues
• Simplifies object protocols
• Abstracts how objects cooperate
• Centralizes control

9
The Mediator Pattern
10
The Façade Pattern

• Description
• Provide a unified interface to a set of
  interfaces in a subsystem. Facade defines a
  higher-level interface that makes the subsystem
  easier to use.
• Applicability
• Need to provide a simple interface to a complex
  system
• Need to decouple a subsystem from its clients
• Need to provide an interface to a software layer
• Consequences
• Shields clients from subsystem components
• Promotes weak coupling between the subsystem and
  its clients

11
Façade Pattern Problem
Subsystem classes
12
Facade Pattern Solution
Facade
Subsystem classes
13
The Façade Pattern
14
The Proxy Pattern

• Description
• Provide a surrogate or placeholder for another
  object to control access to it.
• Applicabilty
• Remote proxies can hide the fact that a real
  object is in another address space
• Virtual proxies can create expensive objects on
  demand.
• Protection proxies can control access to an
  object.
• Smart references can perform additional action
  above a simple pointer

15
The Proxy Pattern
16
The Adapter Pattern

• Description
• Convert the interface of a class into another
  interface clients expect
• Adapter lets classes work together that could not
  otherwise because of incompatible interfaces
• Applicability
• Need to use an existing class whose interface
  does not match
• Need to make use of incompatible classes
• Consequences
• Class adapter commits to the concrete Adapter
  class
• Class adapter introduces only one object and no
  pointer indirection

17
The Adapter Pattern
18
The Bridge Pattern

• Description
• Decouple an abstraction from its implementation
  so that the two can vary independently
• Applicability
• Need to provide a stable, uniform interface that
  is both closed open
• Interface is closed to prevent direct code
  changes
• Implementation is open to allow extensibility
• Need to manage dynamic memory more transparently
  robustly
• Consequences
• Shields the use of inheritance dynamic binding

19
The Bridge Pattern
20
The Abstract Factory Pattern

• Description
• Provides an interface for creating families of
  related or dependent objects without specifying
  their concrete classes.
• Applicability
• Need to abstract from details of implementation
  of products
• Need to have multiple families of products
• Need to enforce families of products that must be
  used together
• Need to hide product implementations and just
  present interfaces
• Consequences
• Isolates concrete classes
• Makes exchanging product families easy
• Promotes consistency among products
• Supporting new kinds (in each family) of products
  is difficult

21
The Abstract Factory Pattern
22
Abstract Factory Example
23
Key points

• OOD is an approach to design in which design
  components have private state and operations
• The Unified Modeling Language provides different
  notations for defining different object models
• Object-oriented design simplifies system
  evolution
• Design patterns are generic, reusable design
  templates
• The three types of patterns are creational,
  structural, and behavioral