CSPP 51023 "'Tis some visitor," I muttered, "tapping at my chamber door; Only this and nothing...
-
date post
19-Dec-2015 -
Category
Documents
-
view
213 -
download
0
Transcript of CSPP 51023 "'Tis some visitor," I muttered, "tapping at my chamber door; Only this and nothing...
CSPP 51023
"'Tis some visitor," I muttered, "tapping at my chamber door;
Only this and nothing more."— Edgar Allen Poe, The Raven
The Visitor Design Pattern
CSPP 51023
Ikbal R. Houssaini , [email protected]
Introduction
Scenario 1
Scenario 2
Scenario 3
Conclusion
Questions & Answers
Outline
Last updated: Sunday, Feb 17, 2002Jun Wu, [email protected]
Scenario 1Homeowners CommunityHouses with distinct characteristics
Different kind/level of maintenance and repairs jobs required
CSPP 51023
Scenario 1Scenario 1
CSPP 51023
Scenario 1Scenario 1
CSPP 51023
Scenario 1Scenario 1
CSPP 51023
Scenario 1Scenario 1
CSPP 51023
Scenario 1Scenario 1
IntroductionProblem
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.
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.
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.
Purpose
behavioral: focus is on interaction and responsibility distribution
Scope
object: focus is on dynamic run-time relationships (assembly)
Introduction
NodeType2
Accept (NodeVisitor)accessOperation()
NodeVisitor
VisitorOp1VisitorOp2
VisitNodeType1(NodeType1)VisitNodeType2(NodeType2)...
Client
NodeType1
Accept (NodeVisitor)accessOperation()
Node
Accept (NodeVisitor)accessOperation()
Scenario 2Hierarchy of modem objectsThe base class has the generic methods common to all modems
You have a requirement to add a new method to the hierarchy to configure the modem to work with the Unix operating system
The derivatives represent the drivers for many different modem manufacturers and types
Source: http://www.cuj.com/java/
CSPP 51023
1
2
3
4
Scenario 2Scenario 2
USR
CSPP 51023
1
2
3
4
Scenario 2Scenario 2
visit (MOT)
CSPP 51023
1
2
3
4
Scenario 2Scenario 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);
}
CSPP 51023
1
2
3
4
Scenario 2Scenario 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;
}
CSPP 51023
1
23 4
Scenario 2Scenario 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; }
}
Scenario 3Real world example in the telecom industry
Visitor used in Composite hierarchy.
CSPP 51023
1
2
3
Scenario 3Scenario 3
CP
(Client)
DSA
(Server)
Data Packet
{
....
…
}
CSPP 51023
1
2
3
Scenario 3Scenario 3
Connection
RsrcPool 1 RsrcPool 2 RsrcPool 3
RsrcRsrc Rsrc Rsrc Rsrc
Container
ElemPool 1 ElemPool 2 ElemPool 3
Elem3Elem1 Elem2 Elem3 Elem1
---@
---@
---@
---@
---@
---@
---@---
@
---@
CSPP 51023
1
2
3
Scenario 3Scenario 3
Connection
RsrcRsrc Rsrc Rsrc Rsrc
Container
ElemPool 1 ElemPool 2 ElemPool 3
Elem3Elem1 Elem2 Elem3 Elem1
Visitor
Op 2Op 1
---@
---@
---@
CSPP 51023
1
2
3
Scenario 3Scenario 3Container
accept(&visitor1)
ElemPool 1
accept(&visitor1) {
visit(this) }
Elem1
accept(&visitor1){
visit(this) }
ElemPool 2
accept(&visitor1) {
visit(this) }
Elem2
accept(&visitor1){
visit(this) }
Visitor 1
visit(elemPool1) {
op1()… }
visit(elemPool2) {
op2()… }
visit(elem2) {
op3()… }
…
Visitor 2
visit(elemPool1) {
op4()… }
visit(elem1) {
op5()… }
…
Conclusion
End
Conclusion
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
AQ &&