Christopher Alexander
Jens Gustavsson
Design Patterns
A design pattern is standard solution for a
standard design problem
Catalogs of patterns exists
Patterns gives a common vocabulary
Create alternating areas of light and dark throughout the
building, in such a way that people naturally walk toward the
light, whenever they are going to important places: seats,
entrances, stairs, passages, places of special beauty, and make
other areas darker, to increase the contrast.
Therefore:
In a building with uniform light level, there are few "places"
which function as effective settings for human events. This
happens because, to a large extent, the places which make
effective settings are defined by light.
TAPESTRY OF LIGHT AND DARK
z
z
z
Conclusions
1
z
z
z
Performance
Safety
Security
Reliability
Usability
z
z
z
Portability
Maintainability
Testability
Other qualities
z
z
z
z
z
Functionality
Runtime qualities
What is good software design?
Example: Facade
Goal: reuse design information
A Design Pattern is a standard solution for a
standard design problem in a certain context.
Software Design Patterns
2
Applicability
Use the Facade pattern when:
z you want to provide a simple interface to a complex subsystem. This makes
subsystems more reusable and easier to customize.
z there are many dependencies between clients and the implementation
classes of an abstraction. Introduce a facade to decouple the subsystem
from other subsystems, thereby promoting subsystem independence and
portability.
z you want to layer your subsystems. Use a facade to define an entry point to
each subsystem level.
Intent
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.
Structuring a system into subsystems helps reduce complexity. A common
design goal is to minimize the communication and dependencies between
subsystems. … example …
Motivation
Facade
Facade
Facade
Example: Facade
How to describe design
patterns?
3
Patterns do not contain new ideas!
The Facade pattern offers the following benefits:
1.
It shields clients from subsystem components, thereby reducing the
number of objects that clients deal with and making subsystem easier
to use.
2.
It promotes weak coupling between subsystem and its clients. Weak
coupling lets you vary the components of the subsystem without
affecting its clients.
3.
It doesn't prevent applications from using subsystem classes if they
need to.
Consequences
Facade
Structure
Participants
Collaborations
Implementation
Sample Code
Known Uses
Related Patterns
Composite, motivation
z
z
z
z
z
z
z
Facade
Text
4
aLine
aText
aCircle
aRectangle
aCircle
aLine
aLine
aText
aPicture
aLine
aCircle
Composite, motivation
aRectangle
aPicture
Composite, motivation
aLine
aPicture
aLine
Text
z
z
Represent part-whole hierarchies of objects
Ignore difference between compositions of
objects and individual objects
Composite, applicability
Composite, motivation
5
Leaf
z
z
z
Makes the client simple
Easy to add new kinds of components
Can make design too general
Composite, consequences
operation()
add(Component)
remove(Component)
getChild(int)
Composite
*
operation()
add(Component)
remove(Component)
getChild(int)
operation()
Client
Component
Composite, structure
1
0%
10%
20%
30%
40%
50%
a
b
c
move()
setColor()
a = 10%
b = 30%
c = 40%
move()
setColor()
Line
1
0%
10%
20%
30%
40%
50%
a
b
c
move()
setColor()
add(VisualComponent)
remove(VisualComponent)
getChild(int)
Picture
move()
setColor()
*
add(VisualComponent)
remove(VisualComponent)
getChild(int)
Rectangle
Observer
move()
setColor()
Circle
Client
VisualComponent
Composite, our example
6
When an abstraction has two aspects, one dependent on the other.
When a change to one object requires changing others.
When an object should be able to notify other objects without making
assumptions about who these objects are.
update
attach
setState
getState
:ConcreteObserver
notify
:ConcreteSubject
attach
getState
update
attach
getState
update
:ConcreteObserver
:ConcreteObserver
Observer, collaborations
z
z
z
Applicability
Observer
observerState
update()
getState()
setState()
z
z
z
Abstract coupling between Subject and
Observer
Support for broadcast communication
Unexpected updates
Observer, consequences
ConcreteObserver
ConcreteSubject
* update()
Observer
subjectState
attach(Observer)
detach(Observer)
notify()
Subject
Observer, structure
7
mouseClicked()
keyPressed()
z
z
z
z
Facade
Composite
Observer
State
Design Patterns
mouseClicked()
keyPressed()
SelectionTool
mouseClicked()
keyPressed()
DrawingController
CreationTool
Client
State, example
mouseClicked()
keyPressed()
ZoomTool
mouseClicked()
keyPressed()
Tool
handle()
handle()
ConcreteStateB
handle()
ConcreteStateC
handle()
State
General Responsibility
Assignment Software Patterns
GRASP Patterns
ConcreteStateA
request()
Context
State, structure
8
1
2
0..32
Player
Piece
position
z
z
z
Facade controller
Role controller
Use-case controller
Game
Board
1
2
0..32
Player
Piece
position
Assign the responsibility for handling a system
event message to a class representing one of
the following choices:
Controller
Game
Board
z
z
z
Game
Board
1
2
0..32
Player
Piece
position
A design pattern is standard solution for a
standard design problem
Catalogs of patterns exists
Patterns gives a common vocabulary
Conclusions
z
z
z
B aggregates A objects
B contains A objects
B records instances of A objects
B closely uses A objects
Assign class B the responsibility to create an
instance of class A if one of the following is
true:
Assign a responsibility to the information expert
- the class that has the information necessary
to fulfill the responsibility.
z
Creator
Expert
9