Chapter 8 Structural Design Patterns Requirements Analysis Process

Chapter 8 Structural Design Patterns

Requirements Analysis Process Phases Discussed in This Chapter Design Framework. Architecture Detailed Design Key: x = main emphasis x = secondary emphasis Implementation Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Facade Design Purpose Provide an interface to a package of classes Design Pattern Summary Define a singleton which is the sole means for obtaining functionality from the package. Notes: the classes need not be organized as a package; more than one class may be used for the façade. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Facade Design Pattern Structure 1 Client Façade «exposed» c. Method. Of. Facade() 2 C «not exposed» my. CMethod() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for Façade : Client singleton : Facade : C c. Method. Of. Facade() my. CMethod() (return if any) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Using Façade for Architecture of a Video Game My. Game. Engine My. Game. Characters «facade» My. Game. Cast «facade» My. Game. Environment «facade» Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goals At Work: Reusability Correctness and Collecting customer-related classes in a package with a clear interface clarifies the design, allows independent verification, and makes this part reusable. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Account. Exception Customer Account get. Customer. Name() get. Num. Accounts() Customer. Exception get. Personal. Note() get. Account( int ) get. Account. Num() deposit( int ) get. Balance() framework Using Façade to Access Bank Customers Bank. Customer 1. . n Bank. Account Intro. Message Bank. Customers «facade» do. Deposit( int amt, Customer cust, Account acc ) get. Bank. Account( Customer cust, int acc. Num ) main() get. Bank. Customer( String cust. Name ) introduce. Application() bank. Customers Client Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Output of Façade Banking Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept: Facade Design Pattern -- modularizes designs by hiding complexity Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Decorator Design Purpose Add responsibilities to an object at runtime. Design Pattern Summary Provide for a linked list of objects, each encapsulating responsibility. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Decorator Class Model Client Component 1 add( Component ) do. Action() Substance. Decoration do. Action() obj. Decorated void do. Action() { …. . // do actions special to this decoration obj. Decorated. do. Action(); // pass along } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

client: Client decoration 1: Decoration Objects in Decorato r decoration 1. object. Decorated: Decoration …. : Substance Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for Decorator : Client decoration 1 Decoration 1. obj. Decorated : Substance : Decoration do. Action() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Output of Customer/Account Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Decorator Applied to Customer / Attempt. To. Add. Banking. Component. Exception Accounts Example Client Setup Banking. Component 1 add( Component ) describe() Customer Account describe() next. Component Check. Account. Savings. Account. CDAccount describe() get. Last. Check. Num(): intget. Interest. Rate(): intget. Duration(): int Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Use of Decorator in java. io Input. Stream Reader 1 Input. Stream. Reader Buffered. Reader Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

: Buffered. Stream. Reader java. io Decorator example : Input. Stream. Reader System. in: Input. Stream Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept: Decorator Design Pattern -- allows addition to and removal from objects at runtime Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Composite Design Purpose Represent a Tree of Objects Design Pattern Summary Use a Recursive Form in which the tree class aggregates and inherits from the base class for the objects. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Basis for Composite Class Model Objects non-leaf node Classes Component leaf node 1. . n “every object involved is a Component object” Non. Leaf. Node “non-leaf nodes have one or more components” Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Composite Class Model Component Client add( Component ) do. It() 1. . n FOR ALL elements e in compone e. do. It() Leaf. Node Non. Leaf. Node do. It() component Type. ANon. Leaf. Node Type. BNon. Leaf. Node etc. do. It() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for Composite : Client non. Leaf 1 : Non. Leaf. Node non. Leaf 1 Child. X : Non. Leaf. Node : Leaf. Node do. It() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Employee Hierarchy Pete : President Able : Manager Lonny : Teller Cal : Clerk Becky : Manager Tina : Teller Thelma : Teller Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goal At Work: Flexibility, Correctness We need to add and remove employees at runtime and execute operations on all of them. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Bank/Teller Example Employee Client 1. . n state. Name() reports Clerk Teller Supervisor state. Name() add(Employee) Setup Manager President state. Name() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for Bank/Teller Example : Setp : Client * do. Client. Tasks() pete : President xxxx : Employee state. Name() • Creates the tree of Employee objects with Pete as President Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Output of Bank/Teller Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Composit e in java. awt Component Container Window Canvas 1. . n component …. . Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Attempt to Simplify Composite Component children 0…n Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept: Composite Design Pattern -- used to represent trees of objects. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Adapter Design Purpose Allow an application to use external functionality in a retargetable manner. Design Pattern Summary Write the application against an abstract version of the external class; introduce a subclass that aggregates the external class. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Adapter Example Abstract. Class client. Name. For. Required. Method() Client Required. Class required. Method() adaptee Adapter client. Name. For. Required. Method() { adaptee. required. Method(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for Adapter : Client : Abstract. Class : Adapter adaptee : Required. Class client. Name. For. Required. Method() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goal At Work: Flexibility and Robustness We want to separate the application as a whole from financial calculations which will be performed externally. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Adapter Design Pattern Application Adaptation Legacy system Financial amount() Principle compute. Value() Client Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Java Listeners as Adapters action. Listener Action. Listener Result of button press My. Button My. Class add. Action. Listener() my. Method() Adaptation My. Listener action. Performed() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Adapter Example: Inheritance Version Abstract. Class standin. For. Required. Method() Required. Class required. Method() Client Adapter standin. For. Required. Method() { required. Method(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept: Adapter Design Pattern -- to interface flexibly with external functionality. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Flyweight Design Purpose Manage a large number of objects without constructing them all. Design Pattern Summary Share representatives for the objects; use context to obtain the effect of multiple instances. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Flyweig ht Class Model Client Flyweight. Factory get. Flyweight(Characteristic) Flyweight 1. . n Flyweight do. Action(Context) Concrete. Flyweight do. Action(Context) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for Flyweight : Client : Flyweight. Factory flyweight : Flyweight get. Flyweight() flyweight Get context . . do. Action( context ) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Input ABBRA CADABBRAA ARE THE FIRST TWO OF MANY 1 WORDS IN THIS FILE … Input color: RED …. . Starting character: 2 … Ending 2 character: 3 Flyweight Example: Text Magnifier Output o o v v v v o - R E D - o o o v v v v o o v v v . . . v v v Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

When Space is No Limitation: Linked Big. Character Objects A 1: Big. ACharacter color == “red” “black” letter…“o”… B 1: Big. BCharacter color==“red” letter…“v”… B 2: Big. BCharacter color “black” letter “v”… R 1: Big. RCharacter color “black” letter “x”… A 2: Big. ACharacter color “black” letter “o”… Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goal At Work: Space Efficiency We want to avoid proliferating an object for every big character to be displayed. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Mapping “A”, “B” etc. to a Big. A Big. B etc. object Client Responsibilities DP Responsibilities Use string to ABBRA CADABBRA … Make (shared) determine which Big. A, Big. B, … flyweight. Use flyweight color information object available color “RED” begins 0 … to form the to clients context big. A: Big. A (parameter value). get. Matrix( ”red” ) v v v Line v v for output big. B: Big. B v . . . - v r e d v - b v l a c v v v v k get. Matrix( “black” ) Flyweights (1 each) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Typical Output For Large Type Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Big. Character Flyweight Application: Class Model Page. Printer Big. Char. Factory get. Flyweight( char ) Application of Flyweight Big. Char construction. Char get. Matrix( String color ) 26 «singleton» Big. A Big. B Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept: Flyweight Design Pattern -- to obtain the benefits of a large set of individual objects without efficiency penalties. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Proxy Design Purpose Avoid the unnecessary execution of expensive functionality in a manner transparent to clients. Design Pattern Summary Interpose a substitute class which accesses the expensive functionality only when required. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Client Proxy Design Pattern Real. Active. Class expensive. Method() another. Method() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Adaptation Instantiate with Base. Active. Class expensive. Method() Proxy object another. Method() Proxy real. Active. Object expensive. Method() another. Method() . . . // One way to check if really needed: if ( real. Active. Object == null ) // never referenc { real. Active. Object = get. Real. Active. Object(); real. Active. Object. expensive. Method(); } else // try to avoid calling the real expensive. Method

Sequence Diagram for Proxy : Client : Proxy : Real. Active. Class expensive. Method() ( if needed: ) real. Expensive. Method() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

I/O of Telephone Record Proxy Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goal At Work: Efficiency and Reuse Avoid unnecessary data downloads. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Proxy Example Telephone. App display( Tel. Nums ) display Middle. Record() static Remote. Tel. Nums 1 remote. Tel. Nums get. Tel. Nums() Tel. Nums value: Vector get. Tel. Nums(): Vector show. Middle. Record() Tel. Nums. Proxy get. Tel. Nums() Setup Ensures that Telephone. App makes calls with Tel. Nums. Proxy . . . // One way to check if really needed: if ( value == null ) // never referenced remote. Tel. Nums. get. Tel. Nums(); else // no need to call ‘get. Tel. Nums()’ Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept: Proxy Design Pattern -- to call expensive or remote methods. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Summary of Structural Patterns Structural Design Patterns relate objects (as trees, lists etc. ) o Facade provides an interface to collections of objects o Decorator adds to objects at runtime o Composite represents trees of objects o Adapter simplifies the use of external functionality o Flyweight gains the advantages of using Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

“Queuing Configuration ” Exercise Key: “c” == a customer Queues Custome r being served ccc c c ccccc c c Teller s Lonny Juani ta Tina Thelm a Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Solution to Exercise 8. 1 “Queueing Configurations” Queue Client …. () Queue. For. One. Teller …. () Setup 1. . n queues Teller Queue. For. Tellers add( Queue Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Inventory. Item. Exception Inventory. Item …( … ) inventory. Framework Xinventory 1 1. . n …( … ) Toaster Using Façade XIntro. Message Client main() XInventory. Facade «facade» …( … ) x. Inventory Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Decorator Applied to Construction Example construction Client Setup 1 Construction. Component add( Component ) show. Price() Constr. Job Constr. Material add() show. Price() next. Component show. Price() Window Door Beam show. Price() … Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Typical Stencil Placement on a Wall Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Typical Wall Perspective etc. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.