CSPP 51023 "'Tis some visitor," I muttered, "tapping at my chamber door; Only this and nothing...

Post on 19-Dec-2015

213 views 0 download

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 , ikbal@uchicago.edu

Introduction

Scenario 1

Scenario 2

Scenario 3

Conclusion

Questions & Answers

Outline

Last updated: Sunday, Feb 17, 2002Jun Wu, wujunuc@hotmail.com

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 &&