Based on slides of: Mira Balaban Department of Computer Science
Ben-Gurion university F. Tip, J. Vlissides, J. Cooper, IBM T J
Watson Research Center. R. Whitney, San-Diego State University.
D.C. Schmidt, Vanderbilt University. Design Patterns --
Introduction Software Engineering Design Patterns -- Introduction
Software Engineering 2011 Department of Computer Science Ben-Gurion
university
Slide 2
Software Engineering, 2011Design Patterns -Introduction 2
Sources 1. Classical text: Design Patterns: Elements of Reusable
Object-Oriented Software, Gamma, Helm, Johnson, Vlissides, (GoF),
1995 2. Java Design Patterns A Tutorial, J.W. Cooper, 2000.
(available online) 3. Applied Java Patterns, S. Stelting, O.
Maassen, 2002. 4. Patterns home page: http://hillside.net/patterns/
http://hillside.net/patterns/
Slide 3
Software Engineering, 2011Design Patterns -Introduction 3 What
is a Pattern? The term design pattern was coined in the mid-1970s
by Christopher Alexander, an architect, who abstracted common
design patterns in architecture and formalized a way of describing
the patterns in a pattern language. A design pattern addresses both
a problem that occurs repeatedly in our environment and the core of
the solution to that problembut at a level of generality that the
solution can be applied many times without ever being the same in
its particulars.
Slide 4
Software Engineering, 2011Design Patterns -Introduction 4 What
is a Pattern? "Each pattern is a three-part rule, which expresses a
relation between a certain context, a problem, and a solution"
Christopher Alexander on architecture patterns A Pattern Language,
Christopher Alexander, 1977 "Patterns are not a complete design
method; they capture important practices of existing methods and
practices uncodified by conventional methods" James Coplien
Software Patterns, James Coplien, 1996, 2000,
http://www1.belllabs.com/user/cope/Patterns/WhitePaper/
Slide 5
Software Engineering, 2011Design Patterns -Introduction 5
Example: A Place To Wait (Alexander 1977) Fundamental problem: How
to spend time wholeheartedly and Still be on hand when doctor,
airplane etc arrive The solution: Fuse the waiting with other
activity that keeps them in earshot Playground beside Pediatrics
Clinic Horseshoe pit next to terrace where people waited Allow the
person to become still meditative A window seat that looks down on
a street A protected seat in a garden A dark place and a glass of
beer A private seat by a fish tank
Slide 6
Software Engineering, 2011Design Patterns -Introduction 6
Example: A Place To Wait (Alexander 1977) The Solution: "In places
where people end up waiting create a situation which makes the
waiting positive. Fuse the waiting with some other activity -
newspaper, coffee, pool tables, horseshoes; something which draws
people in who are not simple waiting. And also the opposite: make a
place which can draw a person waiting into a reverie; quiet; a
positive silence The active part might have a window on the street
- STREET WINDOWS (164), WINDOW PLACE (180), a cafe - STREET CAFE
(88), games, positive engagements with the people passing by -
OPENING TO THE STREET (165). The quiet part might have a quiet
garden seat - GARDEN SEAT (176), a place for people to doze
SLEEPING IN PUBLIC (94), perhaps a pond with fish in it - STILL
WATER (71). To the extent that this waiting space is a room, or a
group of rooms, it gets its detailed shape from LIGHT ON TWO SIDES
OF EVERY ROOM (159) and THE SHAPE OF INDOOR SPACE (191).STREET
WINDOWS (164)WINDOW PLACE (180) STREET CAFE (88)OPENING TO THE
STREET (165)GARDEN SEAT (176)SLEEPING IN PUBLIC (94)STILL WATER
(71)LIGHT ON TWO SIDES OF EVERY ROOM (159)THE SHAPE OF INDOOR SPACE
(191)
Slide 7
Software Engineering, 2011Design Patterns -Introduction 7
Example: Chicken and Egg (Anthony 1996) The Problem Two concepts
are each a prerequisite of the other To understand A one must
understand B To understand B one must understand A A "chicken and
egg" situation Patterns for Classroom Education, Dana Anthony, pp.
391- 406, Pattern Languages of Program Design 2, Addison Wesley,
1996
Slide 8
Software Engineering, 2011Design Patterns -Introduction 8
Example: Chicken and Egg (Anthony 1996) Constraints and Forces
First explain A then B Everyone would be confused by the end
Simplify each concept to the point of incorrectness to explain the
other one People don't like being lied to The Solution Explain A
& B correctly by superficially Iterate your explanations with
more detail each iteration
Slide 9
Software Engineering, 2011Design Patterns -Introduction 9
Example: A Pattern Language for the Preparation of Software
Demonstrations (Coram 1996) The patterns: 1.Element Identification
2.Catalytic Scenarios 3. Mutable Code 4. Prototyping Languages 5.
Lightweight User Interfaces 6. Judicious Fireworks 7. Archive
Scenarios Demo Prep: A Pattern Language for the Preparation of
Software Demonstrations, Todd Coram, pp. 407-416, Pattern Languages
of Program Design 2, Addison Wesley, 1996
Slide 10
Software Engineering, 2011Design Patterns -Introduction 10
Pattern 1: Element Identification (Coram 1996) The Problem:
Selecting the right features to demo is a critical part of keeping
the customer's confidence The Context Have requirements Working on
demo to easy customers doubts about committing to or continuing
with the software project Forces Need to demonstrate your ability
to deliver "things that work" Need to show some level of
functionality Customer wants to see the product's face - the GUI If
customer is not happy with the demo, they are not likely to like
the end product Demos build confidence and create anticipation
Slide 11
Software Engineering, 2011Design Patterns -Introduction 11
Pattern 1: Element Identification (Coram 1996) The Solution:
Identify key areas that concern the customer Talk to the customer
Listen carefully Stay away from excessive animations or other
visual embellishments Unless the product is a game, the product is
to help the customer get some work done not to entertain people The
product's face can be shown through Lightweight User Interface
(pattern 5) Functionality can be addressed by Prototyping Languages
(pattern 4)
Slide 12
Software Engineering, 2011Design Patterns -Introduction 12
Pattern 2: Catalytic Scenarios (Coram 1996) The Problem: The
customer has specified what they think they want You don't want to
build the wrong thing The Context Starting a project to develop
software based on requirements and specification that have already
been agreed on The Forces Customer may not really know what they
want Requirements may not accurately reflect customer's
requirements Requirements may be ambiguous Customer expects to be
given vision of the finished product Demos consume developer's
resources
Slide 13
Software Engineering, 2011Design Patterns -Introduction 13
Pattern 2: Catalytic Scenarios (Coram 1996) The Solution: Use
demonstrable scenarios as a catalyst to open a dialogue between you
and the customer If the specs are ambiguous - develop alternative
scenarios Do not demonstrate capabilities that will be hard to
incorporate into your design If you do not want to change the spec
make sure the demo scenarios follow the spec Keep demo scenarios
simple and short
Slide 14
Software Engineering, 2011Design Patterns -Introduction 14
Pattern 3: Mutable Code (Coram 1996) The Problem: How much code
should you write for the demo? The Context You have identified your
Catalytic Scenarios and are evaluating the amount of effort
required to develop them The Forces Some demo code Can not be used
in the end product Should not be used in the end product
Development time for demo impacts product development Customer does
not like to pay for developing something twice
Slide 15
Software Engineering, 2011Design Patterns -Introduction 15
Pattern 3: Mutable Code (Coram 1996) The Solution: Build modifiable
code Use tools that support a high level of abstraction GUI
builders Scripting languages Write as little code as possible for
the demo Use as much real code as you can If you build screens then
use Lightweight User Interfaces Prototyping Languages (pattern 4)
discusses integrating demo code into end product
Slide 16
Software Engineering, 2011Design Patterns -Introduction 16
Patterns of Learning (D.C. Schmidt) Successful solutions to many
areas of human endeavor are deeply rooted in patterns An important
goal of education is transmitting patterns of learning from
generation to generation Learning to develop good software is
similar to learning to play good chess
Slide 17
Software Engineering, 2011Design Patterns -Introduction 17
Becoming a Chess Master (D.C. Schmidt) First learn the rules e.g.,
names of pieces, legal movements, chess board geometry and
orientation, etc. Then learn the Principles e.g., relative value of
certain pieces, strategic value of center squares, power of a
threat, etc. To become a master of chess, one must study the games
of other masters These games contain patterns that must be
understood, memorized, and applied repeatedly There are hundreds of
these patterns
Slide 18
Software Engineering, 2011Design Patterns -Introduction 18 What
are design patterns? (J.W. Cooper) Recurring solutions to design
problems you see over and over. (Alpert et al, 1998) A set of rules
describing how to accomplish certain tasks in the realm of software
development. (Pree, 1994) Focus on reuse of recurring architectural
design themes (Coplien and Schmidt, 1995) Address a recurring
design problem that arises in a specific context and presents a
solution to it (Buschmann. et al, 1996) Identify and specify
abstractions that are above the level of single classes or
instances, or of components. (GoF)
Slide 19
Software Engineering, 2011Design Patterns -Introduction 19 More
Paradigms of design patterns Problem Analysis (Fowler) Enterprise
systems (Fowler) Responsibility assignment in system design
(Larman) User interfaces. Web site construction. Software design
(GoF, Coplien, and others)
Slide 20
Software Engineering, 2011Design Patterns -Introduction 20 What
is a Software design pattern? (F. Tip) Related question: what is
the difference between experienced and inexperienced software
designers? experienced designers : know from experience what works
and what doesnt able to recognize standard design problems and
apply proven solutions to them Definition of a software design
pattern: a description of communicating classes and objects that
are customized to solve a general design problem in a particular
context
Software Engineering, 2011Design Patterns -Introduction 22
Learn to apply design patterns to the design process ( J.
Vlissides) find the right patterns understand (un)applicability see
when and how to bend a pattern evaluate design trade-offs
effectively Learn by (counter) example
Slide 23
Software Engineering, 2011Design Patterns -Introduction 23
Software Design Patterns - Motivation OOD methods emphasize design
notations Fine for specification, documentation But OOD is more
than just drawing diagrams Good draftsmen good designers Good OO
designers rely on lots of experience At least as important as
syntax Most powerful reuse is design reuse Match problem to design
experience
Software Engineering, 2011Design Patterns -Introduction 25
Design Patterns A design Pattern abstracts a recurring design
structure comprises class and/or object dependencies structures
interactions Conventions names & specifies the design structure
explicitly purify design experience
Slide 26
Software Engineering, 2011Design Patterns -Introduction 26
Elements of Design Patterns (F. Tip) A design pattern has 4
elements: a name (e.g, Abstract Factory or Visitor) the problem
that the pattern addresses the solution: the program constructs
that are part of the pattern the consequences: the results and
tradeoffs of applying the pattern other factors: problem &
solution have been observed in practice choice of implementation
language important
Slide 27
Software Engineering, 2011Design Patterns -Introduction 27
Goals Codify good design distill & generalize experience aid to
novices & experts alike Give design structures explicit names
common vocabulary reduced complexity greater expressiveness Capture
& preserve design information articulate design decisions
succinctly improve documentation Facilitate
restructuring/refactoring patterns are interrelated additional
flexibility
Slide 28
Software Engineering, 2011Design Patterns -Introduction 28
Classifying Design Patterns (F. Tip) purpose: what a pattern does
creational: concerned with creation of objects structural: related
to composition of classes or objects behavioral: related to
interaction and distribution of responsibility scope class-level:
concerned with relationship between classes and their subclasses
object-level: concerned with object relationship (more dynamic, may
be changed at run-time)
Software Engineering, 2011Design Patterns -Introduction 30
Principles of Object-Oriented Design (F. Tip) Program to an
interface, not an implementation. Favor object composition over
class inheritance.
Slide 31
Software Engineering, 2011Design Patterns -Introduction 31
Class vs. Interface Inheritance (F. Tip) Class inheritance defines
an objects implementation in terms of another objects
implementation mechanism for code & representation sharing
Interface inheritance describes when an object can be used in place
of another (subtyping) many languages (e.g., C++) dont make this
distinction, but Java does An object's class defines how the object
is implemented. The class defines the object's internal state and
the implementation of its operations. An object's type only refers
to its interfacethe set of requests to which it can respond. An
object can have many types, and objects of different classes can
have the same type
Slide 32
Software Engineering, 2011Design Patterns -Introduction 32
Class vs. Interface Inheritance (2) (F. Tip) benefits of class
inheritance extend an applications functionality by reusing
functionality in parent classes lets you get new implementations
almost for free, inheriting most of what you need from existing
classes benefits of interface inheritance clients remain unaware of
specific types of objects they use, and of the classes that
implement these objects using interface inheritance greatly reduces
dependencies between subsystems reduces the impact of changes
Slide 33
Software Engineering, 2011Design Patterns -Introduction 33
Mechanisms for Reusing Functionality (F. Tip) Inheritance versus
Composition class inheritance: define implementation of one class
in terms of another often referred to as white-box reuse: internals
of parent class visible to extending class class inheritance breaks
encapsulation object composition: compose objects to get new, more
complex functionality implemented by giving objects references to
other objects; access these objects via interfaces requires that
objects have well-defined interfaces often called black-box reuse:
no internal details of objects are visible to the class that uses
them composition does not break encapsulation
Slide 34
Software Engineering, 2011Design Patterns -Introduction 34 Pros
& Cons of Class Inheritance (F. Tip) Advantages: directly
supported by the programming language, hence easy to use makes it
easy to modify the reused implementation (by simply overriding a
few methods) Disadvantages: cannot change inherited functionality
at run-time, because inheritance is fixed at compile-time parent
classes define at least part of their subclasses physical
representation, and subclasses are exposed to details of their
parents implementation implementation of subclass becomes very
tightly coupled with implementation of parent change in parent is
likely to require changes in subclass
Slide 35
Software Engineering, 2011Design Patterns -Introduction 35
Delegation (F. Tip) delegation is an alternative to inheritance:
two objects are involved: a receiving object delegates an operation
to its delegate analogy: a subclass that defers a request to its
parent class suppose an object of type C wants to delegate a method
f() to an object of type D: class D defines method f() class C
needs to contain a reference field d to a D-object, which needs to
be initialized C needs a forwarding method f() that calls f() on
d
Slide 36
Software Engineering, 2011Design Patterns -Introduction 36
Delegation: Example (F. Tip) public class Rectangle { private int
width; private int height; public int area(){ return width *
height; } } public class Window { private Rectangle rect; public
int area(){ return rect.area(); } } public class WindowClient {
void someOperation(Window w){... w.area()... } } class Window
delegates its area() operation to a Rectangle instance
Slide 37
Software Engineering, 2011Design Patterns -Introduction 37
(Ab)use inheritance for the same purpose (F. Tip) public class
Rectangle { private int width; private int height; public int
area(){ return width * height; } } public class Window extends
Rectangle { private Rectangle rect; // method area() inherited from
superclass } public class WindowClient { void someOperation(Window
w){... w.area()... } }
Slide 38
Software Engineering, 2011Design Patterns -Introduction 38 Why
use delegation? (F. Tip) inheritance can be more convenient: only
define method f() once no need to forward calls somewhat more
efficient however, it is less flexible: cannot change the
implementation of f() after creating the object in languages with
single inheritance, you can only inherit methods from one
superclass
Slide 39
Software Engineering, 2011Design Patterns -Introduction 39 True
delegation (F. Tip) with inheritance, the method in the superclass
can use dynamic dispatch to invoke methods in a subclass with
delegation, this requires some extra work: pass receiving objects
this pointer as an argument to the delegate delegate invokes
methods on this reference when it needs to invoke methods on
receiving object this form of delegation is called true delegation
for an example of true delegation, see the State design
pattern
Slide 40
Software Engineering, 2011Design Patterns -Introduction 40 When
to use inheritance? (F. Tip) generally speaking, use inheritance
for: is-a relationships that dont change over time situations where
the class containing the actual operation is abstract generally
speaking, use delegation for: has-a, part-of relationships
is-a-role-played-by relationships relationships that change over
time situations where multiple inheritance would be needed (if
language doesnt allow MI)
Slide 41
Software Engineering, 2011Design Patterns -Introduction 41
Designing for change (F. Tip) many design patterns introduce
flexibility to avoid common causes of redesign such as: creating an
object by specifying a class explicitly dependence on specific
operations dependence on hardware/software platform dependence on
object representations or implementations algorithmic dependencies
tight coupling extending functionality by subclassing inability to
alter classes conveniently
Slide 42
Software Engineering, 2011Design Patterns -Introduction 42
Designing for change (R. Whitney) Some common design problems that
GoF patterns that Address: Creating an object by specifying a class
explicitly Abstract factory, Factory Method, Prototype Dependence
on specific operations Chain of Responsibility, Command Dependence
on hardware and software platforms Abstract factory, Bridge
Dependence on object representations or implementations Abstract
factory, Bridge, Memento, Proxy
Slide 43
Software Engineering, 2011Design Patterns -Introduction 43
Designing for change (R. Whitney) Algorithmic dependencies Builder,
Iterator, Strategy, Template Method, Visitor Tight Coupling
Abstract factory, Bridge, Chain of Responsibility, Command, Facade,
Mediator, Observer Extending functionality by subclassing Bridge,
Chain of Responsibility, Composite, Decorator, Observer, Strategy
Inability to alter classes conveniently Adapter, Decorator,
Visitor
Slide 44
GOF: Describing Design Patterns Pattern Name and Classification
The pattern's name conveys the essence of the pattern succinctly. A
good name is vital, because it will become part of your design
vocabulary. Intent A short statement that answers the following
questions: What does the design pattern do? What is its rationale
and intent? What particular design issue or problem does it
address? Also Known As Other well-known names for the pattern, if
any. Motivation A scenario that illustrates a design problem and
how the class and object structures in the pattern solve the
problem. The scenario will help you understand the more abstract
description of the pattern that follows. Applicability What are the
situations in which the design pattern can be applied? What are
examples of poor designs that the pattern can address? How can you
recognize these situations? Structure A graphical representation of
the classes in the pattern using a notation based on the Object
Modeling Technique, interaction diagrams to illustrate sequences of
requests and collaborations between objects.
Slide 45
GOF: Describing Design Patterns Participants The classes and/or
objects participating in the design pattern and their
responsibilities. Collaborations How the participants collaborate
to carry out their responsibilities. Consequences How does the
pattern support its objectives? What are the trade-offs and results
of using the pattern? What aspect of system structure does it let
you vary independently? Implementation What pitfalls, hints, or
techniques should you be aware of when implementing the pattern?
Are there language- specific issues? Sample Code Code fragments
that illustrate how you might implement the pattern in C++ or
Smalltalk. Known Uses Examples of the pattern found in real
systems. We include at least two examples from different domains.
Related Patterns What design patterns are closely related to this
one? What are the important differences? With which other patterns
should this one be used?
Slide 46
Software Engineering, 2011Design Patterns -Introduction 46
Example: The Model/View/Controller (MVC) MVC consists of three
kinds of objects. The Model is the application object the View is
its screen presentation the Controller defines the way the user
interface reacts to user input. Before MVC, user interface designs
tended to lump these objects together. MVC decouples them to
increase flexibility and reuse. MVC decouples views and models by
establishing a subscribe/notify protocol between them. A view must
ensure that its appearance reflects the state of the model.
Whenever the model's data changes, it notifies views that depend on
it. In response, each view gets an opportunity to update itself.
This approach lets you attach multiple views to a model to provide
different presentations. You can also create new views for a model
without rewriting it.
Slide 47
Software Engineering, 2011Design Patterns -Introduction 47
Example: The Model/View/Controller (MVC) Example: a model and three
views. (controllers are not shown) The model contains some data
values, and the views defining a spreadsheet, histogram, and pie
chart display these data in various ways. The model communicates
with its views when its values change, and the views communicate
with the model to access these values.
Slide 48
Software Engineering, 2011Design Patterns -Introduction 48
Example: The Model/View/Controller (MVC) This example reflects a
design that decouples views from models. The design is applicable
to a more general problem: decoupling objects so that changes to
one can affect any number of others without requiring the changed
object to know details of the others. This more general design is
described by the Observer design pattern. Another feature of MVC is
that views can be nested. For example, a control panel of buttons
might be implemented as a complex view containing nested button
views. The user interface for an object inspector can consist of
nested views that may be reused in a debugger.
Slide 49
Software Engineering, 2011Design Patterns -Introduction 49
Example: The Model/View/Controller (MVC) MVC supports nested views
with the CompositeView class, a subclass of View. CompositeView
objects act just like View objects; a composite view can be used
wherever a view can be used, but it also contains and manages
nested views. This design is applicable to a more general problem,
which occurs whenever we want to group objects and treat the group
like an individual object. This more general design is described by
the Composite design pattern. It lets you create a class hierarchy
in which some subclasses define primitive objects (e.g., Button)
and other classes define composite objects that assemble the
primitives into more complex objects.
Slide 50
Software Engineering, 2011Design Patterns -Introduction 50
Example: The Model/View/Controller (MVC) MVC lets you change the
way a view responds to user input without changing its visual
presentation. You might want to change the way it responds to the
keyboard, for example, or have it use a pop-up menu instead of
command keys. MVC encapsulates the response mechanism in a
Controller object. There is a class hierarchy of controllers,
making it easy to create a new controller as a variation on an
existing one. A view uses an instance of a Controller subclass to
implement a particular response strategy; to implement a different
strategy, simply replace the instance with a different kind of
controller. It's even possible to change a view's controller at
run-time to let the view change the way it responds to user input.
For example, a view can be disabled so that it doesn't accept input
simply by giving it a controller that ignores input events.
Slide 51
Software Engineering, 2011Design Patterns -Introduction 51
Example: The Model/View/Controller (MVC) The View-Controller
relationship is an example of the Strategy design pattern. A
Strategy is an object that represents an algorithm. It's useful
when you want to replace the algorithm either statically or
dynamically, when you have a lot of variants of the algorithm, or
when the algorithm has complex data structures that you want to
encapsulate. MVC uses other design patterns, such as Factory Method
to specify the default controller class for a view and Decorator
add scrolling to a view. But the main relationships in MVC are
given by the Observer, Composite, and Strategy design
patterns.
