More Patterns. Acknowledgement: Head-first design patterns

Transcription

1 More Patterns Acknowledgement: Head-first design patterns

2 Chain of Responsibility Acknowledgement: Head-first design patterns

3 Problem Scenario: Paramount Pictures has been getting more than they can handle since the release of the Java-powered Ironman game. From their analysis they get four kinds of l Fan mail from customers that love the new 1 in 10 game l Complaints from parents whose kids are addicted to the game l Requests to put machines in new locations l Spam Task: They need you to create a design that can use the detectors to handle incoming .

4 Chain of Responsibility Create a chain of objects that examine a request Each object examines the request and handles it, or passes it on to the next object in the chain.

5 Chain of Responsibility Handler Client Handler successor HandleRequest() SpamHandler FanHandler ComplaintHandler NewLocHandler HandleRequest() HandleRequest() HandleRequest() HandleRequest()

6 Chain of Responsibility - Structure Client successor Handler HandleRequest() Predecessor ConcreteHandler1 HandleRequest() ConcreteHandler2 HandleRequest()

7 Participants Handler l Defines interface for handling request l Implements successor link ConcreteHandler l Handles all requests for which it is responsible l Has access to successor l Delegates request to successor when not handled directly Client l Initiates request to a ConcreteHandler

8 Benefits and Drawbacks Decouples the sender of the request and its receivers Simplifies the object because it doesn t have to know the chain entire structure Allows for adding or removing responsibilities dynamically by changing the members or order of the chain Commonly used in windows systems to handle events like mouse clicks and keyboard events Execution of a request isn t guaranteed Can be hard to observe the runtime characteristics and debug

9 Decorator Pattern

10 Example - Starbuzz Coffee Beverage description milk soy mocha whip description instance variable is set in each subclass superclass cost() will calculate the costs for all condiments while the overridden cost() in the subclasses include costs for that specific beverage type. getdescription() cost() hasmilk() setmilk() hassoy() setsoy() hasmocha() setmocha() haswhip() setwhip() // other methods HouseBlend DarkRoast Decaf Expresso cost() cost() cost() cost()

11 Constructing a drink order with Decorators Start with the DarkRoast Object cost() DarkRoast Customer wants Mocha Cost() cost() Mocha object type mirrors the object it is decorating. Mocha DarkRoast Customer wants whip Cost() Cost() cost() Whip object type mirrors the object it is decorating. Whip Mocha DarkRoast

12 Decorator pattern Decorators have the same super type as the objects they decorate You can use one or more decorators to wrap an object Given that the decorator has the same super type as the object it decorates, we can pass around a decorated object in place of the original object The decorator adds its own behavior either before and/or after delegating to the object it decorates to do the rest of the job Objects can be decorated at any time, so we can decorate objects dynamically at runtime with as many decorators as we like

13 General Structure

14 Mediator Pattern

15 Problem Scenario: Bob has an amazing auto-house. When Bob stops hitting the snooze button, his alarm clock tells the coffee maker to start brewing. Bob is looking to add additional features: No coffee on the weekends Turn of the sprinkler 15 min. before a shower is scheduled Set the alarm early on trash days

16 Problem Representation Alarm CoffeePot onevent() { checkcalender() checksprinkler() startcoffee() Alarm CoffeePot onevent() { checkcalender() checkalarm() startcoffee() // more stuff } // more stuff } Calender Alarm onevent() { checkdayofweek() dosprinkler() docoffee() doalarm() Calender Sprinkler onevent() { checkcalender() checkshowerr() checktemp() checkweather() // more stuff } // more stuff }

17 Mediator in action Mediator if (alarmevent) { checkcalender() checkshower() checktemp() } if (weekend) { checkweather() // do more stuff } Alarm Mediator CoffeePot if (trashday){ resetalarm() //do more stuff } Calender Sprinkler

18 Example: Drawing Editor The GUI widgets for a drawing editor are interrelated Examples: l l l Insert text enables font widgets and fill widgets Insert 3-D object enables fill-in oriented widgets Insert line or arc enables arrowhead options. How to coordinate all these widgets? Do not want to have every widget know about every other widget!

19 Solution: Mediator Pattern l Mediator/director objects synchronize object collections. l Mediator observes all widgets it coordinates q Example: for drawing, every change to drawing tool is broadcasted by mediator to other connected widgets l More efficient and comprehensible than every widget watching every other one. l Centralized coordination.

20 Example: Drawing Director aclient director adrawingdirector alinetool director afontlistbox director atexttool director anarrowlistbox director

21 Interaction Chart aclient adirector alinetool afontlistbox anarrowlistbox selectline disable enable select

22 Participants Mediator l Interface for communications among colleague objects l Knows all the colleagues l Implements cooperative behavior Colleagues l Know their director / mediator l Communicate with mediator to distribute information to other colleagues

23 Benefits and Drawbacks Increases the reusability of the objects supported by the Mediator by decoupling them from the system Simplifies maintenance of the system by centralizing logic Simplifies and reduces the variety of messages sent between objects in the system Without proper design, the Mediator object itself can become overly complex

24 Visitor Pattern

25 The Problem Situation: q Operations to be performed on the elements of an object structure Desire: q Add new operations without changing the classes q Perform operation in a type-safe manner

26 Example File System Basic Types l Directories mydir l Text Files l Image Files l Sound Files subdir1 subdir2 Operations text1 subsubdir image2 sound2 l Total size l SearchImage image1 sound1

27 Approach #1 Operations in Interface Define all operations at topmost interface Override as necessary in each subclass Issue: adding new operations l l l l Requires change to top most class Requires at least recompilation of all subclasses Typically adds code to each subclass Method bloat

28 Approach #2 - Visitor Define Visitor interface with one method per subclass type (e.g., visitdirectory, visitimage) Define Accept method in topmost Element interface Accept method provided a Visitor object Each class s Accept method calls that class s specific method in the Visitor object. Inside each visitor s method(s) we have access to all functionality of the object being visited

29 Structure

30 Class Diagram File name() size() Accept(FileVisitor v) FileVisitor visitdir(dir d) visittext(text t) Dir size() elements() Accept(FileVisitor v) Text size() linecount() Accept(FileVisitor v) SizeVisitor visitdir(dir d) visittext(text b) retrievesize() TotalLinesVisitor visitdir(dir d) visittext(text t) retrievecount() v.visitdir(this) v.visittext(this)

31 Applicability Many distinct, unrelated operations are to be performed You want to minimize the common interface q Isolates conceptual operation in its own class q Supports different operations in different applications that share the overall object structure. Result q The object structure rarely change q The operations over the structure change frequently

32 Drawbacks Adding new concrete element classes is difficult: q q All visitors must change Here putting functionality in structure probably better New Classes? New Ops? Rare Frequent Rare Either Visitor Frequent Structure Hard