Design Patterns An Introduction

1
Design PatternsAn Introduction

• CMSC 432

2
Outline

• In this lecture well
• have an introduction to design patterns from
• Design Patterns - Elements of Reusable
  Object-Oriented Software by Gamma et al.
• Other Sources
• look at their presentation of design patterns
• begin to look at the facade design pattern

3
What are Patterns?

• 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. Christopher Alexander

4
What Patterns Arent

• Patterns are a generalized concept, an idea
  formed in succinct manner, yet expressible in
  many different ways. They arent
• an exact solution
• the basis of a code catalog

5
Introduction

• Experienced OO designers will tell you that are
  reusable and flexible design is difficult to get
  right
• Experienced designers know not to solve every
  problem from first principles
• They use solutions that have worked for them in
  the past - they reuse design patterns
• A design pattern captures expertise
• Design patterns are not exact recipes or concrete
  designs

6
Why Patterns?

• Design is a challenging task
• Balancing concerns, e.g. performance,
  adaptability,reliability.
• Defining components and their interrelationships.
• Thus experienced designers
• Rarely start from first principles
• Look for similarities to problems solved in the
  past.
• Apply a working "handbook" of approaches
• Patterns make expert knowledge widely available
• Supports focusing on the truly distinctive design
  problems.
• Aids design evaluation at higher level of
  abstraction
• Provides a useful working vocabulary for design.

7
Levels of Patterns

• Patterns occur at every level of development.
• Code Idioms
• Recurring control structure groupings.
• Example sentinel terminated loop.
• System Level Architectural styles
• Recurring system level structures.
• Example layers (e.g., Internet protocols).
• Example client/server (e.g., World Wide Web).
• Subsystem Level Design patterns
• Recurring tactical structures.
• Example iterators to process collections of
  objects.

8
Documenting Patterns

• Motivation or context for a pattern
• Patterns are discovered not invented
• Prerequisites for use
• Description of the program structure that the
  pattern will define
• A list of the participants needed to complete a
  pattern
• Consequences of using the pattern, both positive
  and negative
• Examples of the patterns usage
• Documented via a template

9
The Pattern Name

• The pattern name
• is a handle we can use to describe a design
  pattern its solution and consequences in just a
  few words
• having a vocabulary for patterns is important
  because its a basis for communication amongst
  designers

10
The Problem Definition

• The problem definition describes when to apply
  the problem
• It explains the problem and its context
• It might describe specific design problems such
  as how to represent a particular algorithm as a
  set of objects or describe a set of objects that
  leads to problems in reuse

11
The Solution

• The solution describes the elements that make up
  the design, their relationships, responsibilities
  and collaborations
• The solution doesnt describe a particular
  concrete designer implementation instead it
  describes an abstract description of a design
  problem and how a general arrangement of classes
  solves it.

12
The Consequences

• The consequences are the results and tradeoffs in
  applying the pattern.
• These consequences often involve time/space
  tradeoffs
• They may also address implementation issues as
  well
• Since reuse is often a factor in object oriented
  design the consequences of a pattern may include
  its impact on a systems flexibility,
  extensibility or portability

13
An Example

• The Model/View/Controller(MVC) triad of classes
  is used to build user interfaces in the
  Smalltalk-80 system. Looking at the design
  patterns inside MVC should help you see what is
  meant by the term pattern

14
Model View Controller

• MVC consists of three kinds of objects
• Model - the application object
• View -its screen presentation
• Controller - the way the user interface reacts to
  user input
• Before MVC, these three were lumped together

15
MVC Continued

• MVC decouples the view of an object with the
  object itself
• The decoupling is enabled by establishing a
  subscribe/notify protocol between them. A view
  must ensure that its appearance reflects the
  state of the model. Whenever a models data value
  changes, the model notifies the views that depend
  on it

16
More on MVC

• When a view is notified of a change the view has
  an opportunity to update itself
• the MVC approach lets you attach multiple views
  to an object
• An additional consequence is that one may add
  views without altering the model itself

17
MVC from a Design Pattern Perspective

• The MVC is itself a design pattern
• There are also additional patterns to be
  discussed here
• the MVC decouples the model from the view - the
  pattern that allows decoupling of objects so that
  changes to one can affect changes to any number
  of others without requiring the changed object to
  know the details of the affected object is called
  the Observer pattern

18
Other Design Patterns

• We could think of the MVC as a design that lets
  us treat a composite view just like we treat one
  of its components. The MVC has three components
  but we treat it as an user interface system.
• In like manner whenever we what to group objects
  and treat the group like an individual object we
  can use the Composite pattern.

19
The Facade Pattern

• Intent
• Provide a unified interface to a set of
  interfaces in a subsystem in a subsystem, the
  facade provides a higher level interface that
  makes the subsystem easier to use
• A picture makes this concept easier to understand

20
The Facade Pattern Idea
Facade
21
Motivation

• Structuring a system into subsystems helps reduce
  complexity
• A common design goal is to minimize the
  communication and dependencies between subsystems
  or at least isolate them
• The face design pattern enables to do this

22
An example

• Consider for example a programming environment
  that gives applications access to its compiler
  subsystem
• This system contains classes such as a Scanner,
  Parser, programmed , BytecodeStream and
  ProgramNodeBuilder that implement the compiler

23
An example continued

• Some clients need access to these lower level
  classes but in general most clients do not care
  about the details they only want to compile some
  code
• To provide a higher level interface that can
  shield clients from these classes the compiler
  subsystem might also include a Compiler class
  which will provide a unified interface to the
  compilers functionality

24
The example continued

• This Compiler class then acts as a facade
• it offers clients a single simple interface to
  the compiler subsystem
• it glues together the classes that implement the
  compilers functionality without hiding them
  completely
• the compiler facade makes life easier for most
  programmers without hiding the lower-level
  functionality from the few that need it

25
Applicability of the Facade Pattern

• Use the Facade pattern when
• you want to provide a simple interface to a
  complicated subsystem - wrapping a subsystem with
  a facade make using it easier as the subsystem
  evolves
• there are many dependencies between clients and
  the implementation classes in an abstraction

26
Applicability of the Facade Pattern Continued

• Use the facade pattern when
• You want to layer your subsystems.
• Use a facade to define an entry point to each
  subsystem level.
• If subsystems are dependent, then you can
  simplify the dependencies between them by making
  them communicate with each other solely through
  their facades

27
Participants

• Facade (Compiler)
• knows which subsystem classes are responsible
  for a request
• delegates client request to appropriate subsystem
  objects
• subsystem classes (Scanner, Parser,etc)
• implement subsystem functionality
• handle work assigned by the Facade object
• have no knowledge of the facade (i.e. keep no
  references to it)

28
Collaborations

• Clients communicate with the subsystem by sending
  requests to the Facade objects which forwards the
  request to the appropriate subsystem object or
  objects
• Facade may do more than delegation
• Clients do not have access to the subsystem
  objects directly

29
Consequences

• The Facade pattern offers the following benefits
• It shields clients from subsystem components
  reducing the number of objects that clients must
  deal with making the subsystem easier to use
• It promotes weak coupling between subsystem and
  client. Often subsystems are strongly coupled
  making them hard to reuse and change

30
Consequences Continued

• It does not prevent clients from using subsystem
  components if they need to do so.
• It does control the use of the subsystem

31
References

• http//www.swenet.org8080/Overall/SoftDesign/Desi
  gnPatterns1/Patterns.pdf
• Design Patterns, Erich Gamma, Richard Helm, Ralph
  Johnson, John Vlissides ,Addison-Wesley Pub Co,
  1995 1st Ed