Introduction:Today we talk about Visitor design pattern which is one of the behavioral design patterns.We point out which basic problem can be solved by this pattern and see how it can be improved to use with reflection for a more elastic solution.
The visitor design pattern is used when there are different value typed objects in a collection and we need similar operation to do on these objects. The UML graphic can be seen in Figure 1.
Figure 1
Lets first work on a collection that include different objects without visitor pattern.
List heterogenList = new ArrayList();
heterogenList.add("A");
heterogenList.add(1);
heterogenList.add(Calendar.getInstance());
for (Iterator iterator = heterogenList.iterator(); iterator.hasNext();) {
Object heterogenElement = (Object) iterator.next();
if (heterogenElement instanceof String) {
String myString = (String) heterogenElement;
System.out.println("myString:" + myString);
//do sth with the value
}
else if (heterogenElement instanceof Integer) {
Integer myInteger = (Integer) heterogenElement;
System.out.println("myInteger:" + myInteger);
//do sth with the value
}
else if (heterogenElement instanceof Calendar) {
Calendar myCalendar = (Calendar) heterogenElement;
System.out.println("myCalendar:" + myCalendar);
//do sth with the value
}
}
heterogenList.add("A");
heterogenList.add(1);
heterogenList.add(Calendar.getInstance());
for (Iterator iterator = heterogenList.iterator(); iterator.hasNext();) {
Object heterogenElement = (Object) iterator.next();
if (heterogenElement instanceof String) {
String myString = (String) heterogenElement;
System.out.println("myString:" + myString);
//do sth with the value
}
else if (heterogenElement instanceof Integer) {
Integer myInteger = (Integer) heterogenElement;
System.out.println("myInteger:" + myInteger);
//do sth with the value
}
else if (heterogenElement instanceof Calendar) {
Calendar myCalendar = (Calendar) heterogenElement;
System.out.println("myCalendar:" + myCalendar);
//do sth with the value
}
}
As can be seen to read the different objects from the collection we need to use instanceof keyword in the loop.That means if we add a different typed object to our collection, we need to add a new if statement to our source code. If we are continuosly using if keyword in our code, it shows that we do some mistake and we have to revise our design.Instead of if, we can use abstraction to obtain more elastic, tracable and maintainable software.In addition, changing an already tested code after each new type added to our collection is against the open-closed design principle and is a situation that we have to escape. In this case the visitor design pattern comes to rescue.
Lets first define the interfaces and classes that we need.
Lets first define the interfaces and classes that we need.
//Visitor interface
public interface Visitor {
void visit(WrappedString wString);
void visit(WrappedCalendar wCalendar);
void visit(WrappedInteger wInteger);
}
void visit(WrappedString wString);
void visit(WrappedCalendar wCalendar);
void visit(WrappedInteger wInteger);
}
//The interface of the object that will be visited
public interface Element {
void accept(Visitor visitor);
}
void accept(Visitor visitor);
}
//The objects that will be used in the list to visit
public class WrappedString implements Element {
private String name;
private String wString;
public WrappedString(String name, String wString) {
this.name = name;
this.wString = wString;
}
public String getName() {
return name;
}
public String getwString() {
return wString;
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
private String name;
private String wString;
public WrappedString(String name, String wString) {
this.name = name;
this.wString = wString;
}
public String getName() {
return name;
}
public String getwString() {
return wString;
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
public class WrappedInteger implements Element {
private String name;
private int wInt;
public WrappedInteger(String name, int wInt) {
this.name = name;
this.wInt = wInt;
}
public String getName() {
return name;
}
public int getwInt() {
return wInt;
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
private String name;
private int wInt;
public WrappedInteger(String name, int wInt) {
this.name = name;
this.wInt = wInt;
}
public String getName() {
return name;
}
public int getwInt() {
return wInt;
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
import java.util.Calendar;
public class WrappedCalendar implements Element{
private Calendar wCalendar;
private String name;
public WrappedCalendar(String name, Calendar wCalendar) {
this.name = name;
this.wCalendar = wCalendar;
}
public Calendar getWCalendar() {
return wCalendar;
}
public String getName() {
return name;
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
public class WrappedCalendar implements Element{
private Calendar wCalendar;
private String name;
public WrappedCalendar(String name, Calendar wCalendar) {
this.name = name;
this.wCalendar = wCalendar;
}
public Calendar getWCalendar() {
return wCalendar;
}
public String getName() {
return name;
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
//Concrete Visitor
public class ConcreteVisitor implements Visitor {
@Override
public void visit(WrappedString wString) {
System.out.println(wString.getName());
// do sth
}
@Override
public void visit(WrappedCalendar wCalendar) {
System.out.println(wCalendar.getName() + "-" + wCalendar.getWCalendar().getTimeInMillis());
// do sth
}
@Override
public void visit(WrappedInteger wInteger) {
System.out.println(wInteger.getName() + "-" + wInteger.getwInt());
// do sth
}
}
@Override
public void visit(WrappedString wString) {
System.out.println(wString.getName());
// do sth
}
@Override
public void visit(WrappedCalendar wCalendar) {
System.out.println(wCalendar.getName() + "-" + wCalendar.getWCalendar().getTimeInMillis());
// do sth
}
@Override
public void visit(WrappedInteger wInteger) {
System.out.println(wInteger.getName() + "-" + wInteger.getwInt());
// do sth
}
}
Now lets rewrite the previous example with visitor design pattern.
List heterogenList = new ArrayList();
List
heterogenList.add(new WrappedString("wString","A"));
heterogenList.add(new WrappedInteger("wInteger", 1));
heterogenList.add(new WrappedCalendar("wCalendar", Calendar.getInstance()));
Visitor visitor = new ConcreteVisitor();
//Visitor visitor = new AnotherConcreteVisitor();
for (Iterator
Element element = (Element) iterator.next();
element.accept(visitor);
}
Now we get rid of the instanceof keyword.Since all the objects in the collection are implements the Element interface , the only thing we have to do is to read the Element interface from the list and call the accept method with a visitor object.Each of the objects in the list, will pass itself to the visit method of the visitor in its accept method, and in the visitor object the business logic related with the object will be done.The important point here is, the ability to add new visitors with new business logics on the objects without affecting the client code.
Reflective Visitor Design Pattern Implementation:
The visitor design pattern behaves quite elastic adding new visitors, however when we want to add new object to the collection, it requires to change the Visitor interface.In java and all of other object oriented languages, changing an interface after its published is one of the most problematic thing, because when the interface is changed, all of the classes that implement that interface has to be changed.To solve this issue, we can build the visitor interface by reflection.
The reflected interface will be like below.
//Reflective Visitor interface
public interface ReflectiveVisitor {
void visit(Object o);
}
void visit(Object o);
}
//Reflective Element
public interface ReflectiveElement {
void accept(ReflectiveVisitor visitor);
}
void accept(ReflectiveVisitor visitor);
}
//The new object to visit (We change WrappedString class as to implement //ReflectiveElement
public class WrappedDouble implements ReflectiveElement {
private String name;
private double wDouble;
public WrappedDouble(String name, double wDouble) {
this.name = name;
this.wDouble = wDouble;
}
public String getName() {
return name;
}
public double getWDouble() {
return wDouble;
}
@Override
public void accept(ReflectiveVisitor visitor) {
visitor.visit(this);
}
}
private String name;
private double wDouble;
public WrappedDouble(String name, double wDouble) {
this.name = name;
this.wDouble = wDouble;
}
public String getName() {
return name;
}
public double getWDouble() {
return wDouble;
}
@Override
public void accept(ReflectiveVisitor visitor) {
visitor.visit(this);
}
}
public class WrappedString implements ReflectiveElement {
private String name;
private String wString;
public WrappedString(String name, String wString) {
this.name = name;
this.wString = wString;
}
public String getName() {
return name;
}
public String getwString() {
return wString;
}
@Override
public void accept(ReflectiveVisitor visitor) {
visitor.visit(this);
}
private String name;
private String wString;
public WrappedString(String name, String wString) {
this.name = name;
this.wString = wString;
}
public String getName() {
return name;
}
public String getwString() {
return wString;
}
@Override
public void accept(ReflectiveVisitor visitor) {
visitor.visit(this);
}
@Override
public String toString() {
return name + "-" + wString;
}
}
public String toString() {
return name + "-" + wString;
}
}
//Reflective Concrete Visitor
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class AnotherConcreteVisitor implements ReflectiveVisitor {
@Override
public void visit(Object o) {
try {
Method visitMethod = this.getClass().getMethod("visit", new Class[] { o.getClass() });
if (visitMethod == null) {
defaultVisit(o);
} else {
visitMethod.invoke(this, new Object[] { o });
}
} catch (NoSuchMethodException e) {
this.defaultVisit(o);
} catch (InvocationTargetException e) {
this.defaultVisit(o);
} catch (IllegalAccessException e) {
this.defaultVisit(o);
}
}
public void defaultVisit(Object o) {
System.out.println(o.toString());
}
public void visit(WrappedDouble wDouble){
System.out.println(wDouble.getName() + "-" + wDouble.getWDouble());
// do sth
}
}
import java.lang.reflect.Method;
public class AnotherConcreteVisitor implements ReflectiveVisitor {
@Override
public void visit(Object o) {
try {
Method visitMethod = this.getClass().getMethod("visit", new Class[] { o.getClass() });
if (visitMethod == null) {
defaultVisit(o);
} else {
visitMethod.invoke(this, new Object[] { o });
}
} catch (NoSuchMethodException e) {
this.defaultVisit(o);
} catch (InvocationTargetException e) {
this.defaultVisit(o);
} catch (IllegalAccessException e) {
this.defaultVisit(o);
}
}
public void defaultVisit(Object o) {
System.out.println(o.toString());
}
public void visit(WrappedDouble wDouble){
System.out.println(wDouble.getName() + "-" + wDouble.getWDouble());
// do sth
}
}
Lets rewrite the previous example again,
List heterogenList = new ArrayList();
heterogenList.add(new WrappedString("wString","A"));//default visit method
heterogenList.add(new WrappedDouble("wDouble", 1.0));
ReflectiveVisitor visitor = new AnotherConcreteVisitor();
for (Iterator iterator = heterogenList.iterator(); iterator.hasNext();) {
ReflectiveElement reflectiveElement = (ReflectiveElement) iterator.next();
reflectiveElement.accept(visitor);
}
heterogenList.add(new WrappedString("wString","A"));//default visit method
heterogenList.add(new WrappedDouble("wDouble", 1.0));
ReflectiveVisitor visitor = new AnotherConcreteVisitor();
for (Iterator
ReflectiveElement reflectiveElement = (ReflectiveElement) iterator.next();
reflectiveElement.accept(visitor);
}
In this approach, all the objects in our collection are calling the generic visit method of visitor class.
This generic visit method takes Object as parameter, and depending on the type of parameter, calls the related visit method.The important point is, the visitor class has to define visit(data:DataType) method for all data types that it wants to play.If the related visit method cannot be found, there can be a defaultVisit method to do a generic default job.
This generic visit method takes Object as parameter, and depending on the type of parameter, calls the related visit method.The important point is, the visitor class has to define visit(data:DataType) method for all data types that it wants to play.If the related visit method cannot be found, there can be a defaultVisit method to do a generic default job.
Conclusion:
With reflective visitor design pattern, the elasticity of adding new visitors is to be improved to include adding new objects to the collection.When we need to add new object to the already defined visitor, all we need is to add a visit method for the new objects to the visitor class.We don't need to change the ReflectiveInterface interface and other visitors.
However this elasticity comes with a performance loss.Since the method that will be called by reflection determined at runtime dynamically, some JVM optimization cannot be done and so reflected parts can cause very bad performance especially at hot spots.
When we execute the below example in my machine using reflection and without using reflection with 1000000 objects we get 50 times slower results.In addition when we increase the number of objects to 10000000 we get Out of Memory error.
The reason may because of the heap space or perm gen space depending on the situation.If you use heavy reflection then it may the JVM's mechanism called "inflation" to run the reflected method faster causes the Out of Memory error with perm gen.Normally, up to a defined calling number, creating an instance of MethodAccessor which is an inner class defined in Method class, each invoke call send to the MethodAccessor's invoke method by JNI (Java Native Interface). Since the JNI method call is very slow, after some method calls, JVM creates a new class at runtime.This class also include invoke method , the instance of it will be used for the invoke calls instead of JNI calls. This technique is called as inflation, and the performance problem of reflection minimized using this.However even with this improvement we still have 50 times slower results.
The classes and the references of instances of this class are kept in permanent generation part of heap.(In our case only one instance of the class created) (Permanent generation hold class and method definitions, constant pool information (taken from class file), references of object arrays and type arrays associated with the class, classes created at runtime by JVM by inflation, references of static variables, and the information used by JIT for optimization.)
When there is huge amount of reflected method calls with different objects, the classes created for inflation by JVM may cause to fill the permanent generation causing Out of Memory.
In this case you have to reserve enough memory for permanent generation to be used by JVM.
However this elasticity comes with a performance loss.Since the method that will be called by reflection determined at runtime dynamically, some JVM optimization cannot be done and so reflected parts can cause very bad performance especially at hot spots.
When we execute the below example in my machine using reflection and without using reflection with 1000000 objects we get 50 times slower results.In addition when we increase the number of objects to 10000000 we get Out of Memory error.
The reason may because of the heap space or perm gen space depending on the situation.If you use heavy reflection then it may the JVM's mechanism called "inflation" to run the reflected method faster causes the Out of Memory error with perm gen.Normally, up to a defined calling number, creating an instance of MethodAccessor which is an inner class defined in Method class, each invoke call send to the MethodAccessor's invoke method by JNI (Java Native Interface). Since the JNI method call is very slow, after some method calls, JVM creates a new class at runtime.This class also include invoke method , the instance of it will be used for the invoke calls instead of JNI calls. This technique is called as inflation, and the performance problem of reflection minimized using this.However even with this improvement we still have 50 times slower results.
The classes and the references of instances of this class are kept in permanent generation part of heap.(In our case only one instance of the class created) (Permanent generation hold class and method definitions, constant pool information (taken from class file), references of object arrays and type arrays associated with the class, classes created at runtime by JVM by inflation, references of static variables, and the information used by JIT for optimization.)
When there is huge amount of reflected method calls with different objects, the classes created for inflation by JVM may cause to fill the permanent generation causing Out of Memory.
In this case you have to reserve enough memory for permanent generation to be used by JVM.
References and Resources:
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Desing Patterns - Elements of Reusable Object-Oriented Software
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html
