Design Patterns
What is wrong with this picture?
Ball
Enemy
Private:
double gravity 32.1
Private:
double gravity 32.1
Don’t repeat yourself!
How about this?
Global double gravity 3.21
We’re not using a constant because we want to support different worlds with
different gravitational forces.
Why not use globals?
A.
They make code hard to debug.
B.
They make code hard to change.
C.
Profs O’Neill and Kuenning will haunt your dreams if
you do.
Answer: All of the above
This is a Design Pattern....
Design Patterns
A.
B.
C.
D.
E.
Description of the problem.
Essence of a solution
Description of accumulated knowledge.
Book: Design Patterns, by gang of 4.
Web page devoted to software Design
Patterns: http://hillside.net
Elements of a Design Pattern
• Name that is meaningful
• Description of the problem area that explains when the
pattern may be applied
• A solution description of the parts of the design solution,
their relationships, and their responsibilities.
– not a concrete design description, but a template
– many times expressed graphically - UML
• Statement of the consequences of applying the pattern
– results and trade-offs
– used to indicate applicability
The Observer pattern
Pattern name
Observer
Description
Separates the display of the state of an object from the object itself and allows alternative displays
to be provided. When the object state changes, all displays are automatically notified and updated
to reflect the change.
Problem
description
In many situations, you have to provide multiple displays of state information, such as a graphical
display and a tabular display. Not all of these may be known when the information is specified. All
alternative presentations should support interaction and, when the state is changed, all displays
must be updated.
This pattern may be used in all situations where more than one display format for
state information is required and where it is not necessary for the object that maintains the state
information to know about the specific display formats used.
Solution
description
This involves two abstract objects, Subject and Observer, and two concrete objects,
ConcreteSubject and ConcreteObject, which inherit the attributes of the related abstract objects.
The abstract objects include general operations that are applicable in all situations. The state to
be displayed is maintained in ConcreteSubject, which inherits operations from Subject allowing it
to add and remove Observers (each observer corresponds to a display) and to issue a notification
when the state has changed.
The ConcreteObserver maintains a copy of the state of ConcreteSubject and implements the
Update() interface of Observer that allows these copies to be kept in step. The ConcreteObserver
automatically displays the state and reflects changes whenever the state is updated.
The UML model of the pattern is shown in Figure 7.12.
Consequences
The subject only knows the abstract Observer and does not know details of the concrete class.
Therefore there is minimal coupling between these objects. Because of this lack of knowledge,
optimizations that enhance display performance are impractical. Changes to the subject may
cause a set of linked updates to observers to be generated, some of which may not be necessary.
Observer Pattern:
Multiple displays
UML model of the Observer
pattern
Using Design Patterns
• Is a design process
– develop a design
– experiencing a problem
– recognizing that an existing pattern can be
used
– most difficult step is the need for a taxonomy
of Design Patterns
Singleton Pattern
Problem: Ensure a class has only one
instance and provide a global point of
access to that instance.
Singleton Gravity Class
class Gravity
{
public:
users can ask for a pointer to THE instance
static Gravity* getInstance();
double getGravity();
private:
and then get the value for
gravity
static Gravity* theGravityInstance;
Gravity() {};
~Gravity) {};
the constructor is private
Gravity(const Gravity& toCopy) {};
Gravity& operator=(const Gravity& toCopy) {};
};
Gravity::Gravity* theGravityInstance = NULL;
façade Design Pattern
Problem: You need to use a subset of a complex
system or you need to interact with the system
in a particular way.
façade
A facade is an object that provides a simplified
interface to a larger body of code, such as a class
library.
A facade can make a software lib easier to use,
understand and test.
A facade can make code more readable because it
has convenient methods for common tasks
A facade can reduce dependencies of outside code
on library inner workings.
A facade is a wrapper
Triangle2D
Triangle3D
set z=0
2d rotate about origin,
use 3d rotate about <0,0,1>
tuple3D vertices[3]
triangle()
triangle(tuple3D v[3]
~triangle()
set color(r, g, b)
rotate(vector, angle)
translate(dx, dy, dz)
scale(sx, sy, sz)
draw()
etc.
Triangle 2D is special case of Triangle 3D
facade: Triangle2D
Triangle2D
Triangle3D
Triangle3D* myTriangle
tuple3D vertices[3]
triangle()
triangle(tuple2D v[3])
~triangle()
set color(r, g, b)
rotate(angle)
translate(dx, dy)
scale(sx, sy)
draw()
triangle()
triangle(tuple3D v[3])
~triangle()
set color(r, g, b)
rotate(vector, angle)
translate(dx, dy, dz)
scale(sx, sy, sz)
draw()
MORE INTUITIVE,
Hides the 3D
interface.
Strategy design pattern
Problem: Want to be able to swap the
algorithm used in an application at runtime
Solution: Strategy pattern defines a family of
algorithms, encapsulates each one, and
makes them interchangeable
Strategy DP lets the algorithm vary
independently from the clients that use it.
I want to support two (or more) different
collision detection algorithms.
cPhysicsEngine
Encapsulate change
cPhysicsFast
cPhysicsSlow
In the future I may want to use a super slow algorithm.
UML of Strategy DP
Strategy Design Pattern
cPhysicsEngine
cDetectCollision
supports several design principles:
• encapsulate change
• open-closed principle
• single responsibility principles
• favor composition over inheritance
cDetectCollisionFast
cDetectCollisionSlow
Bridge Pattern
Problem: Want to decouple implementation
from abstraction so they can change
independently
A teacher (Communicator object) can talk to any kid (talkable object),
and a kid should also allow any teacher (Communicator object) to
start talking to him/her as well. Just like how printers work with
computers. If we have a USB cable (bridge), then we can connect
any printer to any computer to start printing. It really doesn't
matter if it's a laser printer or a color printer, either Windows PC
or Mac. Because we know all the printers will allow the
computers to print, makes sense?
Bridge
Shape
draw()
abstracts interface
Graphics
package
Decouple abstraction from
implementation
Circle
draw()
Rectangle
draw()
OpenGL
adapter
DirectX
adapter
wrappers
OpenGL
DirectX
State Design Pattern
Problem: want to allow an object to alter its
behavior when its internal state changes
State Design
Pattern
PaintProgram
processKey
processMouse
1
Spray
Paint
supports open-closed, encapsulate
change, single responsibility principles
Mode
processKey
processMouse
Eraser
Fill
State Design Pattern
Mode mgr. returns pointer to correct mode,
i.e., Key or Mouse handling function
PaintProgram
processKey
processMouse
Mode
processKey
processMouse
1
1
ModeManager
processKey
processMouse
Spray
Paint
1
Eraser
1
Fill
1
Command Design Pattern
Encapsulate a request as an object to permit
logging, queuing, un-doing etc.
an object is used to represent and
encapsulate all the info needed to call a
method at a later time. Includes method
name, object that owns that method and
values for any parms,.
Command Design Pattern
Command
Key
Mouse
Menu
MVC Design Pattern
Model-view-Controller
The pattern isolates “domain logic” (application logic for the user) from
the user interface permitting independent development, testing and
maintenance of each (separation of concerns)
• user interacts with user interface, e.g., button
• controller converts into understandable action for the model
• controller tells model of user action (model state may change)
• view queries model to generate user interface; view gets its date from
model.
• view may render itself or is notified by model of changes in state that
require screen update
MVC
supports high
cohesion
and low
coupling
Other design patterns
wikipedia
http://hillside.net
books