230 likes | 374 Views
The Visitor Design Pattern. "'Tis some visitor," I muttered, "tapping at my chamber door; Only this and nothing more." — Edgar Allen Poe, The Raven. Quick Start. Jump Start. Featured. Featured. Basics. ValuPack. ValuPack. Content. Content. Guided Tour. Online. Online.
E N D
The Visitor Design Pattern "'Tis some visitor," I muttered, "tapping at my chamber door; Only this and nothing more."— Edgar Allen Poe, The Raven
Quick Start Jump Start Featured Featured Basics ValuPack ValuPack Content Content Guided Tour Online Online Getting More Information Outline Introduction Scenario 1 Scenario 2 Scenario 3 Conclusion Questions & Answers Ikbal R. Houssaini , ikbal@uchicago.edu Jun Wu, wujunuc@hotmail.com Last updated: Sunday, Feb 17, 2002
Scenario 1 • Homeowners Community Houses with distinct characteristics Different kind/level of maintenance and repairs jobs required
Introduction • Motivation • Can be used to provide an extension to an object hierarchy. • The Visitor abstract class defines methods which will be called whenever an instance of a Visitor is passed to an element in another hierarchy. • Element defines the base class for a hierarchy which knows how to deal with Visitors. The accept() method in the element takes an instance of a Visitor and calls its methods. Solution The Visitor Pattern is used to represent an operation to be performed on the elements of an object structure. Visitors are great ways to extend an existing class hierarchy. Problem You need to add a new method to a hierarchy of classes, but the act of adding it will be painful or damaging to the design. • Purpose • behavioral: focus is on interaction and responsibility distribution • Scope • object: focus is on dynamic run-time relationships (assembly)
Client NodeVisitor Node VisitNodeType1(NodeType1) VisitNodeType2(NodeType2) ... Accept (NodeVisitor) accessOperation() VisitorOp2 VisitorOp1 NodeType1 NodeType2 Accept (NodeVisitor) accessOperation() Accept (NodeVisitor) accessOperation() Introduction
Scenario 2 • Hierarchy of modem objects The base class has the generic methods common to all modems The derivatives represent the drivers for many different modem manufacturers and types You have a requirement to add a new method to the hierarchy to configure the modem to work with the Unix operating system Source: http://www.cuj.com/java/
USR Scenario 2 1 2 3 4
visit (MOT) Scenario 2 1 2 3 4
Scenario 2 public interface Modem { public void dial(String pno); public void hangup(); public void send(char c); public char recv(); public void accept(ModemVisitor v); } public interface ModemVisitor { public void visit(HayesModem modem); public void visit(MotModem modem); public void visit(ErnieModem modem); } 1 2 3 4
Scenario 2 public class HayesModem implements Modem { public void dial(String pno){} public void hangup(){} public void send(char c){} public char recv() {return 0;} public void accept(ModemVisitor v) {v.visit(this);} String configurationString = null; } 1 2 3 4
Scenario 2 public class UnixModemConfigurator implements ModemVisitor { public void visit(HayesModem m) { m.configurationString = "&s1=4&D=3"; } public void visit(MotModem m) { m.configurationValue = 42; } } 1 2 3 4
Scenario 3 • Real world example in the telecom industry Visitor used in Composite hierarchy.
Scenario 3 CP (Client) Data Packet { .... … } 1 2 3 DSA (Server)
---@ ---@ ---@ ---@ ---@ ---@ ---@ ---@ ---@ Scenario 3 Connection Container RsrcPool 1 ElemPool 1 ElemPool 2 RsrcPool 2 ElemPool 3 RsrcPool 3 1 2 3 Rsrc Elem1 Elem2 Rsrc Elem3 Rsrc Elem1 Rsrc Elem3 Rsrc
---@ ---@ ---@ Scenario 3 Visitor Connection Container Op 1 Op 2 ElemPool 1 ElemPool 2 ElemPool 3 1 2 3 Elem1 Rsrc Elem2 Rsrc Elem3 Rsrc Elem1 Rsrc Elem3 Rsrc
Scenario 3 Visitor 2 visit(elemPool1) { op4()… } visit(elem1) { op5()… } … Visitor 1 visit(elemPool1) { op1()… } visit(elemPool2) { op2()… } visit(elem2) { op3()… } … Container accept(&visitor1) ElemPool 1 accept(&visitor1) { visit(this) } ElemPool 2 accept(&visitor1) { visit(this) } 1 2 3 Elem1 accept(&visitor1){ visit(this) } Elem2 accept(&visitor1){ visit(this) }
Conclusion Conclusion End • PROS: • Multi-Dispatch capability • New operations easy to add. • Gathers related operations into one place. • Visiting across hierarchies is easy. • Weakness: • Adding Element classes is hard • May force more features into the public interface than is desirable. A related pattern: Interpreter - distribute code over class Hierarchy Vs. Visitor - centralize code in single class
A Q &