design patterns. what is wrong with this picture? ball double gravity 32.1 private: enemy double...

30
Design Patterns

Upload: esther-banks

Post on 24-Dec-2015

220 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Design Patterns

Page 2: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

What is wrong with this picture?

Ball

double gravity 32.1Private:

Enemy

double gravity 32.1Private:

Don’t repeat yourself!

Page 3: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: 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 withdifferent gravitational forces.

Page 4: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

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 aboveThis is a Design Pattern....

Page 5: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Design Patterns

A. Description of the problem.

B. Essence of a solution

C. Description of accumulated knowledge.

D. Book: Design Patterns, by gang of 4.

E. Web page devoted to software Design Patterns: http://hillside.net

Page 6: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

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

Page 7: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

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.

Page 8: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Observer Pattern: Multiple displays

Page 9: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

UML model of the Observer pattern

Page 10: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

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

Page 11: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Singleton Pattern

Problem: Ensure a class has only one instance and provide a global point of access to that instance.

Page 12: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Singleton Gravity Classclass Gravity

{

public:

static Gravity* getInstance();

double getGravity();

private:

static Gravity* theGravityInstance;

Gravity() {};

~Gravity) {};

Gravity(const Gravity& toCopy) {};

Gravity& operator=(const Gravity& toCopy) {};

};

Gravity::Gravity* theGravityInstance = NULL;

users can ask for a pointer to THE instance

and then get the value for gravity

the constructor is private

Page 13: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

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.

Page 14: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

façadeA 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

Page 15: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Triangle2D

Triangle3D

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()

set z=0

2d rotate about origin, use 3d rotate about <0,0,1>

etc.

Triangle 2D is special case of Triangle 3D

Page 16: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

facade: Triangle2D

Triangle3D

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()

Triangle2D

Triangle3D* myTriangle

triangle()triangle(tuple2D v[3])~triangle()set color(r, g, b)rotate(angle)translate(dx, dy)scale(sx, sy)draw()

MORE INTUITIVE, Hides the 3D interface.

Page 17: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

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.

Page 18: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

cPhysicsEngine

cPhysicsFast

I want to support two (or more) differentcollision detection algorithms.

cPhysicsSlow

In the future I may want to use a super slow algorithm.

Encapsulate change

Page 19: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

UML of Strategy DP

Page 20: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

cPhysicsEngine cDetectCollision

cDetectCollisionFast

Strategy Design Pattern

cDetectCollisionSlow

supports several design principles:•encapsulate change•open-closed principle•single responsibility principles•favor composition over inheritance

Page 21: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

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?

Page 22: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Bridge

Shapedraw() Graphics

package

DirectXadapter

OpenGL adapter

OpenGL DirectX

Circledraw()

Rectangledraw()

Decouple abstraction from implementation

abstracts interface

wrappers

Page 23: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

State Design Pattern

Problem: want to allow an object to alter its behavior when its internal state changes

Page 24: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

PaintProgramprocessKey

processMouse

ModeprocessKey

processMouse

EraserSprayPaint

Fill

State Design Pattern

1

supports open-closed, encapsulatechange, single responsibility principles

Page 25: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

PaintProgramprocessKey

processMouse

ModeprocessKey

processMouse

EraserSprayPaint

Fill

State Design Pattern

1

ModeManagerprocessKey

processMouse

1 1 1

1

Mode mgr. returns pointer to correct mode, i.e., Key or Mouse handling

function

Page 26: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

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,.

Page 27: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Command

MouseKey Menu

Command Design Pattern

Page 28: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

MVC Design PatternModel-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

Page 29: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

MVC

supports high cohesionand low coupling

Page 30: Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!

Other design patterns

wikipediahttp://hillside.netbooks