Download Design Patterns

Design Patterns
Visitor
SE516
Melisa Tyira
A design pattern describes a solution to a design problem that can be used over
and over again. The key to the goal of a design pattern is the reuse of objects in order to
avoid rework. The use of existing objects is a major factor towards software
productivity.
A design pattern is described using the following elements: pattern name,
problem, solution, and consequences. A pattern name is given to each design pattern in
order to increase our vocabulary thus being able to discuss design patterns freely without
having to give a description each time. The problem is a description of the design
problem, which also leads to a description of when to apply the pattern. The solution is
not a description of a specific design that will solve the problem but a description of the
elements and interactions between these elements that make up the design. The
consequences are the positive and negative results of applying a design pattern. It is
beneficial to decide the pros and cons of applying a design pattern in order to determine if
there are truly benefits to applying a design pattern.
There are many documented design patterns and groups of these design patterns
are related in some way to one another. These groups of design patterns are: creational
patterns, structural patterns, and behavioral patterns. I will discuss the Visitor design
pattern, which is classified as a behavioral pattern. There are two types of behavioral
patterns: behavioral class patterns and behavioral object patterns. Behavioral class
patterns are concerned with how objects and classes communicate and their pattern of
communication between them. Behavior is distributed among classes by inheritance.
Behavioral object patterns are not concerned with inheritance but are concerned with
object composition. Some behavioral object patterns describe how objects work together
2
to perform a task while others encapsulate the behavior in one single object and other
objects interact with this object. Visitor is a behavioral object pattern that encapsulates
behavior instead of distributing among classes.
Visitor encapsulates an operation to be performed on elements of an object
structure and this pattern enables you to define an operation without changing the classes
that it operates on. Visitor makes adding new operations easy. When a new visitor is
added, new operations are also added. In doing this, the operation being performed on a
structure can be changed without changing the classes of elements being operated on.
Consider the example of a department of employees (including manager and
engineers). An outside consultant or finance executive occasionally come to meet with
the employees in the department. The consultant and finance executive are considered to
be visitors. The visitors are escorted to each cubicle and while being escorted, they do
not perform any action. Once they arrive at the proper cubicle, they act as needed with
the employees. This example is described in the following diagram:
Department
Client
EscortVisitor
Visitor
Employee
VisitMgr
VisitEngnr
AcceptVisit
ReceivePay
Consultant
FinanceExec
Manager
Engineer
VisitMgr
VisitEngnr
VisitMgr
VisitEngnr
AcceptVisit
ReceivePay
AcceptVisit
ReceivePay
3
The Consultant and Finance Executive correspond to the Visitor.
The Consultant and Finance Executive also correspond to the ConcreteVisitor, but
the purpose of the visit determines the ConcreteVisitor.
The Element corresponds to the office visited.
The employee occupying the office corresponds to the ConcreteElement.
The schedule or agenda of the visit corresponds to the ObjectStructure.
This allows easy addition of new visitors. There is no need to change the classes that the
visitor operates on (Employee). This example takes on the form displayed in the
following diagram. This is a general display of the Visitor design pattern.
Object Structure
Client
Visitor
Element
VisitConcreteElementA(ConcreteElementA)
VisitConcreteElementB(ConcreteElementB)
Accept(Visitor)
ConcreteVisitor1
ConcreteVisitor2
ConcreteElementA
ConcreteElementB
VisitConcreteElementA(ConcreteElementA)
VisitConcreteElementB(ConcreteElementB)
VisitConcreteElementA(ConcreteElementA)
VisitConcreteElementB(ConcreteElementB)
Accept(visitor v)
OperationA()
Accept(visitor v)
OperationB()
v-> VisitConcreteElementA(this)
v-> VisitConcreteElementB(this)
The Visitor must declare an operation for each ConcreteElement class. The
Visitor can access the element directly through its interface.
The ConcreteVisitor implements the operations declared by the Visitor.
4
The Element defines an operation in which a visitor is an argument.
The ConcreteElement implements the operation and takes visitor as an argument.
The Visitor pattern makes it easy to add a new operation. The new operation can
be added without changing existing classes by adding a new visitor. The visitor also
keeps related operations together and keeps unrelated operations separate. All related
operations are contained in a visitor. This simplifies classes and the algorithms defined
in the visitor. One of the problems with the visitor design is that it makes adding new
ConcreteElement classes tough. Most of the time, when a new ConcreteElement is
added, a new abstract operation needs to be added to Visitor and a corresponding
implementation needs to be added in every ConcreteVisitor class.
Composite pattern and Interpreter pattern are both related to the Visitor pattern.
The composite pattern divides objects into tree structures in order to treat individual
objects and the composed objects uniformly. The visitor pattern can be applied as an
operation over a structure of objects defined by composite. The Interpreter pattern takes
a given language and defines a representation for its grammar and interprets the language.
Visitor can be used to provide the interpretation.
As a simple example, the visitor pattern can be described as a taxi company.
When a person calls a taxi company to use their services, they are added to the
company’s list. The company dispatches a taxi, which, to the customer, becomes the
visitor and the customer accepts the visitor. When the customer enters the taxi (Visitor),
the customer is no longer in control of the transportation. This describes a real-world
example that makes Visitor easy to understand.
5
Sample Code
Abstract Visitor
Visitor.java
Concrete Visitor
Consultant.java
FinanceExec.java
Visitor.java
public abstract class Visitor
{
private String title;
public void setTitle(String titleIn)
{
this.title=titleIn;
}
public final String getTitle(Employee employee)
{
return employee.getTitle();
}
public void visit(Employee employee)
{
this.setTitle("Title: " + employee.getTitle());
}
}
Consultant.java
public class Consultant extends Visitor
{
public void visit(Employee employee)
{
System.out.println("Thank you for visiting. My name is " + employee.getTitle());
}
}
FinanceExec.java
public class FinancExec extends Visitor
{
public void visit(Employee employee)
{
System.out.println("Thank you for visiting. My name is " + employee.getTitle());
}
}
6
Element
Employee.java
Concrete Element
Manager.java
Engineer.java
Employee.java
public abstract class Employee
{
public String title;
public abstract void accept(Visitor visitor);
public final String getTitle()
{
return this.title;
}
public void setTitle(String titleIn)
{
title = titleIn;
}
}
Manager.java
public class Manager extends Employee
{
public Manager(String title)
{
this.setTitle(title);
}
public void accept(Visitor visitor)
{
System.out.println("Accepting Visitor");
}
}
Engineer.java
public class Engineer extends Employee
{
public Engineer(String title)
{
this.setTitle(title);
}
public void accept(Visitor visitor)
{
System.out.println("Accepting Visitor");
}
}
7
TestVisitor.java
class TestVisitor
{
public static void main (String[] args)
{
Employee manager = new Manager("John Q. Manager");
System.out.println(manager.getTitle() + " has been named as manager.");
Visitor consultant = new Consultant();
manager.accept(consultant);
System.out.println("Consultant is visiting manager.");
consultant.visit(manager);
System.out.println("*************************************************
************");
Employee engineer = new Engineer("Sal E. Engineer");
System.out.println(engineer.getTitle() + " has been named as engineer.");
Visitor financeexec = new FinancExec();
manager.accept(financeexec);
System.out.println("Finance Executive is visiting engineer.");
financeexec.visit(engineer);
}
}
8
References
Gamma, Erich & Helm, Richard & Johnson, Ralph & Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Design
http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes
http://www.agcs.com/supportv2/techpapers/patterns/papers/patexamples.htm
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/tutorial.html
9