Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Design Patterns – Group 2 Iterator, Proxy, Adapter, Decorator

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (1) –pp. 315 – 355 of HFDP –A behavior design pattern –An object pattern –Intent Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (2) –Problem Situation I: Wish to dynamically choose between alternative methods of moving over a collection Situation II: Wish to provide access to elements held in local data structure without exposing data structure itself Situation III: Wish to define a generic iteration process that is independent of the data structure used for storing the objects

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (3) –Non-software example (1) Receptionist in Doctor’s Office Receptionist provides Doctor with iterate over patients The iterator

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (4) –Non-software example (2) Channel Surfing –TVs no longer have explicit channel indicators –Use generic “next” “prev” buttons –Cable allows personal iterators to be defined

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (5) –Abstract Description GoF presents one form – object pattern Object Pattern What are these about?

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (6) –Consequences Provide variations in traversal algorithm –Breaks tie with data structure Simplifies the data structure interface –Doesn’t require each type of traversal to be defined in interface Allows multiple simultaneous traversal –Iterator holds the state information –Must be careful if the iterator supports mutation of the data structure

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (7) –Implementation Issues (1) Who controls the iteration? –Client »called external iterator »must advance iterator and request next object »Most common approach »Most flexible approach –Iterator »called internal iterator »client passes process to iterator to be applied to each element »Isolates the iteration process completely to the iterator »Essentially provides ability to do something to each element without releasing each element

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (8) –Implementation Issues (2) Who defines the traversal algorithm? –Aggregate »called cursor iterator »defines the sequence based on the data structure –Iterator »allows different traversals for same aggregate »typically requires access to aggregate implementation »Use “markers” to indicate the current item in the aggregate

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Iterator Design Pattern (9) –Java API Usage java.util.Iterator interface provides hasNext(), next(), and remove() methods remove() is optional –throws UnsupportedOperationException Java Collections Framework uses the Iterator interface in Collection –Iterator iterator()

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (1) –pp. 429 – 490 of HFDP –A structural design pattern –Intent Provide a surrogate or placeholder for another object to control access

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (2) –Problem Situation I: Wish to control access to an object because: –Housekeeping activities are required –Protection levels exist –Objects sit in different address spaces –Actual object too expensive to build immediately Situation II: Wish to provide transparent management of services –The client “thinks” it is using the actual service when rather it is using a proxy for the actual service

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (3) –Non-software example (1) Toll-free numbers –Client dials the “800” area code just like they would for a real area code –Proxy records billing information and connects to actual area code

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (4) –Non-software example (2) Checks –Check is a proxy for the actual funds in the bank

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (5) –Abstract Description (1) GoF presents one form – object pattern Object Proxy Pattern Notice the “is a” and “has a” relations again.

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (8) –Consequences (1) Isolates RealSubject from client –Forces controllable indirection Costs indirection –True for all delegation models May require duplicate information in Proxy and RealSubject –Must support same “properties” –These must be supported even before instantiation of RealSubject

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (9) –Consequences (2) Creates second class dependent on Subject interface –Unavoidable in this pattern Client may need to be aware of Proxy –For example, extra failure modes –Example: java.rmi.MarshalException in RMI

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (10) –Example: Copy-on-write Hash Table (1) java.util.HashTable has expensive clone operation –therefore, implemented as a shallow clone! Solved with copy-on-write –When the proxy's clone() method is invoked, it returns a copy of the proxy and both proxies refer to the same hash table. –When one of the proxies modifies the hash table, the hash table itself is cloned (deep). –A reference-counted hash table class is used to let the proxies know they are working with a shared hash table. This class keeps track of the number of proxies using the shared hash table.

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Proxy Design Pattern (11) –Java API Usage (1) java.rmi library “Remote Method Invocation” Allows objects in separate virtual machines to be used as if local (language specific) Uses “stub and skeleton” to handle communication

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (1) –pp. 235 – 253 of HFDP –A structural design pattern Decouples interface from implementation –Intent Convert the interface of a class into another interface the client expects Primarily for reusing existing code in new situations

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (2) –Problem Situation I: Wish to use an existing class that accomplishes the task but with wrong interface Situation II: Want to dynamically (at run-time) determine which methods/objects respond to a specific request without the client knowing which method/object was selected

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (3) –Non-software example Wrench and socket set

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (4) –Abstract Description (1) GoF presents two different forms –Class adapter – uses multiple inheritance –Object adapter – uses delegation (our preference) Class Adapter

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (5) –Abstract Description (2) Object Adapter –Notice how both the class and object versions involve inheritance –The key is how each version uses the concept Could be an interface

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (6) –Consequences Client and Adaptee remain independent –Can change adaptee if situation arises Introduces additional indirection –Hurts readability –Hurts run-time (in both versions???)

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (7) –Implementation Issues (1) Class Version –Adapter extends abstract Target class –Adapter implements IAdaptee Object Version –Adapter implements ITarget –Adapter has a Adaptee that implements IAdaptee –Notice that the specific adaptee used can change over time

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (8) –Implementation Issues (2) Object Version –How does the Adapter know which Adaptee to use? »Declare its own. - locks in particular concrete implementation »Pass in as a parameter. - requires client to know »Use inner class - avoid explicit definition of Adapter Button done = new Button(“done”); Done.addActionListener( new ActionListener() {…} ); Uses adaptee One more option: Factory method – more on this later

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (9) –Java API Usage Most common – event handling through inner classes

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Adapter Design Pattern (10) –Compare Adapter & Façade Design Patterns Common Misperception –Façade deals with multiple classes and Adapter deals with one Key: Adapter converts an interface and façade simplifies one FacadeAdapter Are there preexisting classes?Yes Is there an interface we must design to?NoYes Does an object need to behave polymorphically? NoProbably Is a simpler interface needed?YesNo

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Decorator Design Pattern (1) –pp. 79 – 108 of HFDP –A structural design pattern An object design pattern –Intent Allows you to add varied layers of objects to “decorate” another object without changing code in the class hierarchies What is the difference between the Decorator and Proxy design patterns?

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Decorator Design Pattern (2) UML Diagram

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Decorator Design Pattern (3) –Proxy vs. Decorator (1) Decorator can use Composite –Proxy does not Decorator can add additional functions –Proxy does not Proxy can duplicate information –Decorator does not Decorator contains “static” reference to Component –Proxy’s reference changes over lifetime »Protection proxy most similar »Remote proxy does not contain reference to RealSubject »Virtual proxy will at times contain reference to RealSubject and at times will not

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Decorator Design Pattern (4) –Proxy vs. Decorator (2) Decorator created by client –Proxy created for client Main Difference - Intent –Proxy is intended to stand in for other object –Decorator is intended to augment other object –You will see this kind of difference among several of the design patterns