bts530: major project planning and design

16
Basic Design Pattern Concepts All References and Material unless otherwise specified From: Applying UML and Patterns, 3 rd Edition, chapter 25 BTS530: Major Project Planning and Design

Upload: september-alvarado

Post on 03-Jan-2016

23 views

Category:

Documents


1 download

DESCRIPTION

BTS530: Major Project Planning and Design. Basic Design Pattern Concepts All References and Material unless otherwise specified From: Applying UML and Patterns, 3 rd Edition, chapter 25. Basic Patterns/Concepts. Controller Use Case / Session Façade For protecting from variations - PowerPoint PPT Presentation

TRANSCRIPT

Basic Design Pattern ConceptsAll References and Material unless otherwise

specified From: Applying UML and Patterns, 3rd Edition, chapter 25

BTS530: Major Project Planning and Design

Basic Patterns/Concepts Controller

Use Case / SessionFaçade

For protecting from variationsFor simplicity

Polymorphism

Use Case / Session Controller What first object beyond the UI controls

(receives and coordinates) a system operation?

A “controller” objectUses use case logic to determine how a

message from the UI should be handledCan be considered a special type of Facade

Design Patterns, p. 302

Use Case / Session Controller

: Customer :

DepositHandler : Account

deposit($100)

setBalance(+100)

FacadeKnows which subsystem classes are

responsible for a requestDelegates subsystem requests to

appropriate subsystem objects“Protects” and/or “Simplifies”

Design Patterns, p. 461

Façade-protect from variations

: Customer :

DepositHandler : Account : DBFacade

: Database :

AccountMapper

deposit($100)

setBalance(+100)

replace(...)

UI BusinessLogic

DataServices

Façade-simplify

The home tv example:“client” talks to one object—the

HomeTheatreFacade Much simpler than talking to:

Amplifier Tuner Dvd player Etc.

One function “watch movie” initiates all required functions from other classes

Each individual component can be accessed if required

Adapted from Head First Design Patterns, by Freeman, Freeman, Sierra, Bates, p258

watchDVDMovie might look like the following:

tuner.on()amplifier.on()amplifier.setSurroundSound()amplifier.setVolume(default)amplifier.setDVD()tv.on()tv.setDVD()dvd.play(movie)

Only a sample of functions is shown; there are probably many more functions

HomeTheatreFacade

watchCableTV()endCableTV()watchDVDMovie()endDVDMovie()

DVDPlayer

on()off()eject()pause()play()rewind()setRewindSpeed()close()

TV

on()off()setDVD()setCable()turnLeft()turnRight()setVolume()setChannel()

Amplifier

on()off()setStereoSound()setSurroundSound()setVolume()setDVD()setTV()setCable()

Tuner

on()off()setAM()setFM()setFrequency()

CablePVR

on()off()startRecord()endRecord()play()pause()rewind()setRewindSpeed()remove()

Subsystem

Façade-simplify

: Client : LoadDVDHandler : DVDPlayer

loadMovie(PiratesOfTheCarribean)

close()

eject()

eject() : Client

: WatchMovieHandler

: HomeTheatreFacade

watchDVDMovie()

watchDVDMovie(PiratesOfTheCarribean)

Still have accessto each componentin the subsystem

Provides a simple interface

to a complex subsystem

PolymorphismThe Problem:How do you handle alternatives based

on type? How do you create pluggable software components?if/then/else or case conditional logic is

difficult to maintain difficult to extend a program with new variations

how can you replace one server component with another without affecting the client?

PolymorphismA Suggestion/Solution:When alternatives/behaviours vary by

type (class): assign responsibilities for the behaviours

using polymorphic operations to the types for which the behaviour varies.

polymorphic => same name is given to services (methods) of different objects—the services might vary.usually implement a common interface or are in a

hierarchy with a common superclass (this is language dependent)

Fig. 25.1

TaxMasterAdapter

getTaxes( Sale ) : List<TaxLineItems>

GoodAsGoldTaxProAdapter

getTaxes( Sale ) : List<TaxLineItems>

«interface»ITaxCalculatorAdapter

getTaxes( Sale ) : List<TaxLineItems>

By Polymorphism, multiple tax calculator adapters have their own similar, but varying behavior for adapting to different external tax calculators.

<???>Adapter

...

...

Problem1: how to support 3rd party tax calculators?

Fig. 25.2

Problem2: in the game Monopoly a different action is initiated when players land on different squares—for example landing on GO initiates “receive $200”. What is the behaviour that varies? Why don’t we want to test for the type of an object and use conditional logic to handle this, all in one class?

why?

why?

What this looks like in a sequence diagram.

Fig. 25.3

why? why?

Fig. 25.4-25.7

For individual squares:

Fig. 25.4-25.7

For individual squares: