20
Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Embed Size (px)

Citation preview

Page 1: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Design Patterns

Ric Holt & Sarah Nadi

U Waterloo, March 2010

Page 2: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

What is a Design Pattern

• A Design Pattern systematically names, explains, and implements an important recurring design.

• These define well-engineered design solutions that practitioners can apply when crafting their applications.

2

Page 3: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Why Design Patterns?

• Good designers do not solve every problem from first principles. They reuse solutions.

• Practitioners do not do a good job of recording experience in software design for others to use. Patterns help solve this problem.

3

Page 4: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Four Example Patterns

1. MVC (Model View Controller)

2. Adapter

3. Facade

4. Factory

4

Page 5: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

1. MVC Pattern(Model View Controller)

• There is a model (subject) which can be thought of as the application

• There are one or more views of the object (by observers)

• There is a controller that mediates between the model and the view(s).

5

Page 6: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Example MVC

a b ca

bc

[Mancoridis picture]

Views

Controller

Modela b c

503020

a = 50%b = 30%c = 20%

6

Page 7: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Example MVC

a b ca

bc

[Mancoridis picture]

Views

Controller

Modela b c

503020

a = 50%b = 30%c = 20%

See

Interact

7

Page 8: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Multiple View Problem

• Need to keep all the views consistent

• If user (or one of users) changes a view, all other views should be updated

8

Page 9: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Information Hiding:Insulating Model from Presentation

• The model is the “back end” or “business logic”, or “application”

• To minimize complexity, the model should know as little as possible about– How users interact with system– How many users are there– Any other models

9

Page 10: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Implementing MVC

• There are many choices– Where is list of views (observers) kept?– How is notification of change transmitted?– How manage web interface?– Should a view ask for (or should it be told of)

details about changes?

10

Page 11: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

What Kind of Pattern is MVC?

• Design pattern proper?– Use it for structuring modest configurations

• Architectural pattern?– Use it for overall structure of a software

system, defining interactions among services, browsers etc.

11

Page 12: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

2. Adapter Pattern

• You have an existing client (application) that uses an old interface to an existing support package.

• You are given a new interface to a new support package

• You need to produce an adapter so that:– The client can use the new interface instead of

the old one (without changing the client)

12

Page 13: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Illustration of Adapter Pattern

ClientOld

package

Old interfac

e

Client Adapter

Old interfac

e New package

New interfac

e

13

Page 14: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Implementing Adapter Pattern Using Object Composition

ClientOld Interface

Request()

New Interface

SpecificRequest()

Adapter

Request() SpecificRequest()

adapteeinherit

14

Page 15: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Advantages of Adapter Pattern

• Can change behavior of existing software without changing its source code

• Can be used for legacy software

• Do not need access to old source code

15

Page 16: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

3. Facade Pattern

• A facade provides a single simplified interface to a larger part of the system (a subsystem)

• The facade makes this subsystem more readable and easier to understand

• Having facades minimizes communication and dependencies between subsystems

16

Page 17: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Structure of the Facade Pattern

17

Subsystem Classes

Facade

[Mancoridis picture]

Page 18: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

Adapter vs. Facade

• An Adapter is used when the wrapper must respect a particular interface and must support a polymorphic behavior. On the other hand, a facade is used when one wants an easier or simpler interface to work with

18

Page 19: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

4. Factory Pattern

• A creational pattern dealing with creating objects without knowing their concrete class

• It defines an interface for creating an object, but let the subclasses decide which class to instantiate

• Useful when concrete class of object should be decided at runtime according to parameters

19

Page 20: Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010

How does it work

20

<abstract>

Product

<Implementation Class>

ProductA<Implementation Class>

ProductB

<static>ProductFactory

createProduct(in param) : Product

Produces different subclasses of Product according to parameters

inherits