chapter 6 introduction to design patterns. process phase discussed in this chapter requirements...
TRANSCRIPT
Process Phase Discussed in This ChapterRequirementsAnalysis
Design
Implementation
ArchitectureFramework Detailed Design
xKey: = secondary emphasisx = main emphasis
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Sample Design Goals and Ways to Accomplish Them
Reusability, Flexibility, and Maintainabilityo Reuse flexible designso Keep code at a general levelo Minimize dependency on other classes
Robustness o Reuse reliable designso Reuse robust parts
Sufficiency / Correctnesso Modularize designo Reuse trusted parts
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
KitchenViewer Interface
Wallcabinet
Counter
Floorcabinet
Modern Classic Antique Arts & Crafts
menu
display area
styles
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
KitchenViewer Example
Modern Classic Antique Arts & Crafts
Wall cabinets Floor cabinetsCountertop
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Selecting Antique Style
Modern Classic Antique Arts & CraftsAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
KitchenViewer Without Design Patterns
Kitchen
ClientrenderKitchen()
FloorCabinet
ModernWallCabinet
ModernFloorCabinet AntiqueFloorCabinet
AntiqueWallCabinet
WallCabinet
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design Goal At Work: Flexibility
Our design should be flexible enough to produce any of several kitchen styles.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
AntiqueKStylegetWallCabinet()getFloorCabinet()
The Abstract Factory Idea
KitchenStylegetWallCabinet()getFloorCabinet()
ModernKStylegetWallCabinet()getFloorCabinet()
WallCabinet FloorCabinet
AntiqueWallCabinet AntiqueFloorCabinet
FloorCabinet getFloorCabinet() { return new AntiqueFloorCabinet(); }
……
FloorCabinet getFloorCabinet() { return new ModernFloorCabinet(); }
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Abstract Factory Design Pattern Applied to KitchenViewer
KitchenStylegetWallCabinet()getFloorCabinet()
KitchengetWallCabinet()getFloorcabinet()
ClientrenderKitchen( KitchenStyle )
ModernKStylegetWallCabinet()getFloorCabinet()
AntiqueKStylegetWallCabinet()getFloorCabinet()
WallCabinet FloorCabinet
ModernWallCabinet
ModernFloorCabinet
AntiqueWallCabinet
AntiqueFloorCabinetAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Abstract Factory Design Pattern
StylegetComponentA()getComponentB()
ClientdoOperation( Style myStyle )
Style1getComponentA()getComponentB()
Style2getComponentA()getComponentB()
ComponentA ComponentB
Style1ComponentA
Style1ComponentB
Style2ComponentA
Style2ComponentB
Collection
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Abstract Factory Design PatternAlternative
StylegetComponentA()getComponentB()
ClientdoOperation()
Style1getComponentA()getComponentB()
Style2getComponentA()getComponentB()
ComponentA ComponentB
Style1ComponentA
Style1ComponentB
Style2ComponentA
Style2ComponentB
Collection getComponentA()getComponentB()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Design Pattern
-- class combination and algorithm fulfilling a common design purpose.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Creational Design Patterns
-- used to create objects in flexible or constrained ways.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Structural Design Patterns
-- used to represent data structures such as trees, with uniform processing interfaces.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Example of Behavioral Design Goal: Port Traffic
berthberth
to drydock
obstacles
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design Goal At Work: Flexibility
Our design should be flexible enough to produce any of several kitchen styles.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Ship Tugboat1..n1
Harbor application
Customs application: reuse Ship alone
Ship Longshoreman
Avoiding Dependencies
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Core Mediator Concept Applied to The Harbor Problem
Ship
Tugboat
LeavingPortestimateTime()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Applying the Mediator Design Pattern to The Harbor Problem
Ship Tugboat
VesselPortMissionestimateTime()
LeavingPortestimateTime()
EnteringPortestimateTime()
BeingMaintainedestimateTime()
Mediator base class
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
You have requested to view a luxury model
with luxury body style, and black body color.
Model
Body Style
Body color
Choose an automobile to view.
OK
A Design Problem Solvable by Chain of Responsibility
Basic Midsize Luxury SUV
Luxury Extra Basic
Black Brown Red White
This part is fixed
Display depends on model selected
Display depends on body style selected
Assume that each of these will eventually be a small, expensive animation.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Behavioral Design Patterns
-- to capture behavior among objects.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Characteristics of Design Patterns 1
Viewpoints – ways to describe patterns1. Static: class model (building blocks)
2. Dynamic: sequence or state diagram (operation)
Levels – decomposition of patterns1. Abstract level describes the core of the pattern
2. Concrete (= non abstract) level describes the particulars of this case
Roles – the “players” in pattern usage 1. Application of the design pattern itself
2. Clients of the design pattern application
3. Setup code initializes and controls
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Characteristics of Design Patterns 21. Client role
2. Setup role
A
C
A. Static viewpoint B. Dynamic viewpoint
3. Role: Application of the design pattern
D
B (i) Abstract level
(ii) Concrete level
(class model)(sequence or
state diagram)
(class or classes)
(class or classes)
: Reference directionAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
getWallCabinet()
Abstract Factory Application Sequence Diagram
myStyle:KitchenStyleClient
myStyle:ModernKStyle
myStyle:AntiqueKStyle
renderKitchen( myStyle )
wallCabinet1:ModernWallCabinet
wallCabinet1:AntiqueWallCabinet
ModernWallCabinet()getWallCabinet()
AntiqueWallCabinet()
myStyle.getWallCabinet()
-- IF myStyle BELONGS TO ModernKStyle --
-- IF myStyle BELONGS TO AntiqueKStyle --
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Two Viewpoints
We consider design patterns from the static viewpoint (what they are made from) and the dynamic viewpoint (how they function).
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Concrete and Abstract Layers
KitchenStyle
Kitchen
Client
ModernKStyle
AntiqueKStyle
WallCabinet
FloorCabinet
ModernWallCabinet
ModernFloorCabinet
AntiqueWallCabinet
AntiqueFloorCabinet
Abstract level
Concrete level
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design Goal At Work: Correctness
We want to provide an interface to a design pattern so that its functionality is clear and separate.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Two Levels
Design patterns usually have an abstract level and a non-abstract (“concrete”) level.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design Goal At Work: Correctness
To use design patterns effectively, we distinguish the roles involved.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
2. Client Role 1. Design Pattern Application
Interface to the pattern
(frequently abstract; possibly
several classes)
DPClient DPInterface
Rest of thedesign pattern
application
Interacts with the design pattern only through its interface
3. Setup Role
The Three Roles Involved in Design Pattern Usage
Rest of the Application
No limitations
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Three Roles
A part of a design either 1) applies a design pattern, 2) is a client of the pattern application, or 3) re/initializes these.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Basic Idea of Delegation
requiredFunction()
… intermediaryFunction( … ){ … requiredFunction() …}
ClientclientFunction() intermediaryFunction()
replace
… clientFunction( … ){… intermediaryFunction( … ) …}
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Basic Design Pattern Form #1: Delegation
DoerBasedoIt()
DPInterfaceinterfaceMethod()
ConcreteDoer1doIt()
ConcreteDoer2doIt()
. . .
doerObject
… interfaceMethod( … ){ … doerObject.doIt() … }
Client
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Basic Design Pattern Form #2: Recursion
RecursionBasedoOperation()
NonrecursiveClassdoOperation()
RecursiveClassdoOperation()
void doOperation( … ){ … aggregate … }
aggregate
Client
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
The Recursion Form Applied to an Organization Chart
EmployeeprintOrganization()
IndividualContributorprintOrganization()
SupervisorprintOrganization()
void printOrganization( … ){ … supervisees.printOrganization() … }
supervisees
Client
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Two Forms
A design pattern’s form is usually a delegation of responsibility or a class that relates to itself (recursive).
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Summary of This Chapter
Design Patterns are recurring designs satisfying
recurring design purposes
Described by Static and Dynamic Viewpoints o Typically class models and sequence diagrams respectively
Use of a pattern application is a Client Roleo Client interface carefully controlled
o “Setup,” typically initialization, a separate role
Design patterns Forms usually Delegation or
Recursion
Classified as Creational, Structural, or Behavioral
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.