Introduction to Java Design pattern access mode (Visitor-mode) _java

Visitor definition: An action that acts on each object in a group of objects. It allows you to define new actions that work on these objects without changing the objects themselves.

In Java, the visitor pattern is actually a separation of elements in the collection structure and the act of manipulating those elements.

Why Use visitor mode
Java collection (including Vector and Hashtable) is the technology we use most often, but collection is like a black big dyeing tank, when objects with distinct types of features are put in and removed, these types disappear. Then we are bound to use if to judge, such as:

Copy Code code as follows:

Iterator iterator = Collection.iterator ()
while (Iterator.hasnext ()) {
Object o = Iterator.next ();
if (o instanceof Collection)
Messyprintcollection ((Collection) o);
else if (o instanceof String)
System.out.println ("'" +o.tostring () + "");
else if (o instanceof Float)
System.out.println (o.tostring () + "F");
Else
System.out.println (O.tostring ());
}

In the example above, we used the instanceof to determine the type of O.

Obviously, the disadvantage code for doing so is that if else if it's cumbersome, we can use the visitor mode to solve it.

How to use visitor mode

For the above example, we design an interface visitor visitor:

Copy Code code as follows:

public interface Visitor
{
public void Visitcollection (Collection Collection);
public void Visitstring (string string);
public void visitfloat (float float);
}

In this interface, we put the types of classes that we think collection possible into.

With the visitor, we need to be the visitor, the visitor is each element of our collection, we want to define an accessible interface for these elements (access and access is interactive, only visitors, if the visitors are not welcome, visitors can not access )。

We define this interface called Visitable, which is used to define a accept operation, which means that collection each element is accessible.

Copy Code code as follows:

public interface visitable{
public void Accept (Visitor Visitor);
}

Well, with two interfaces, we're going to define their specific implementations (concrete Class):

Copy Code code as follows:

public class Concreteelement implements Visitable
{
private String value;
Public concreteelement (String string) {
Value = string;
}
Define the specific contents of the accept here is a very simple sentence call
public void Accept (Visitor Visitor) {
Visitor.visitstring (this);
}
}

Then look at the visitor's concrete implementation:

Copy Code code as follows:

public class Concretevisitor implements Visitor
{
In this method, we implement a successful access to the elements of collection
public void Visitcollection (Collection Collection) {
Iterator iterator = Collection.iterator ()
while (Iterator.hasnext ()) {
Object o = Iterator.next ();
if (o instanceof visitable)
((visitable) O). Accept (this);
}

public void Visitstring (string string) {
System.out.println ("'" +string+ "");
}

public void visitfloat (float float) {
System.out.println (float.tostring () + "F");
}
}

In the above visitcollection we have achieved access to each element of the collection, using only one judgment statement, as long as it is possible to determine whether it is accessible.

So far, we have completed the basic architecture of visitor mode.

The premise of using visitor mode

The type of object in the object group structure (Collection) rarely changes, meaning that the identity type of the visitor is rarely changed, as the type in visitor above is rarely changed, and if additional actions are required, such as in the previous example, in the Concreteelement implementation, A new ConcreteElement2 ConcreteElement3 is also needed.

Visible use of visitor mode is a prerequisite, in two interfaces visitor and visitable, to ensure that visitor very little change, the change is visitable, so the use of visitor is most convenient.

If visitor also changes frequently, that is, the object types in the object group often change, it is generally recommended that you define the actions individually in these object classes, but the Java reflect technology solves the problem.