() Visitor mode
definition: encapsulates certain operations that act on elements of a data structure, and it can define new operations that act on these elements without altering the data structure.
Type: behavior class mode
Class Diagram:
The visitor pattern may be one of the most complex patterns in the behavioral class pattern, but this cannot be a reason why we do not have to master it. Let's start with a simple example with the following code:
Class A {public void Method1 () { System.out.println ("I am a"); } public void Method2 (b b) { B.showa (this);} }
Class B {public void ShowA (a a) { a.method1 ();} }
Let's take a look at the difference between method Method1 and Method method2 in class A , the method method1 very simple, is to print out a "I am a" The method method2 is slightly more complex, uses class B as a parameter, and invokes the ShowA method of class B . Take a look at the ShowA method of Class B , theShowA method uses class a as a parameter and then calls the method1 of class a . method, you can see that themethod2 method around to go around, nothing else is to call their own method1 method, it should also run the results should be "I am a", after analysis, Let's run through these two methods and look at the results of the operation:
public class Test {public static void Main (string[] args) { A A = new A (); A.method1 (); A.METHOD2 (New B ());} }
The result of the operation is:
I'm a, I'm a.
Understanding This example, we understand the 90%of the visitor pattern, in the example, for class A , class B is a visitor. But this example is not all of the visitor pattern, although intuitive, but its scalability is poor, let's say the common implementation of the visitor pattern, through the class diagram can be seen in the visitor pattern, mainly includes the following roles:
Abstract Visitor: an abstract class or interface that declares which elements a visitor can access, specifically to the program in which the parameters in the visit method Define which objects can be accessed.
Visitor: Implements the method that the abstract visitor declares, which affects what the visitor does and does when he accesses a class.
abstract Element class: an interface or abstract class that declares which type of visitor access to accept is defined by the parameters in the Accept method. Abstract elements generally have two types of methods, part of their own business logic, and the other is what kind of visitors are allowed to receive access.
element class: The implements the accept method, which is declared by the abstract element class, and is usually visitor.visit (this) , It's basically a form of a stereotype.
Structure object: a container for an element that typically contains a container that accommodates multiple different classes and interfaces, such as List,Set,Map , and so on, which is rarely abstracted from this role in a project.
Common code implementations for visitor patterns
Abstract class Element {public abstract void accept (Ivisitor visitor); public abstract void DoSomething ();}
Interface Ivisitor {public void visit (ConcreteElement1 el1); public void Visit (ConcreteElement2 el2);
Class ConcreteElement1 extends element {public void dosomething () { System.out.println ("This is element 1"); } public void Accept (Ivisitor visitor) { visitor.visit (this); }}
Class ConcreteElement2 extends element {public void dosomething () { System.out.println ("This is Element 2"); } public void Accept (Ivisitor visitor) { visitor.visit (this); }}
Class Visitor implements Ivisitor {public void visit (ConcreteElement1 el1) { el1.dosomething (); } public void Visit (ConcreteElement2 el2) { el2.dosomething ();} }
Class Objectstruture {public static list<element> getList () { list<element> List = new ArrayList <Element> (); Random ran = new random (); for (int i=0; i<10; i++) { int a = Ran.nextint (+); if (a>50) { list.add (new ConcreteElement1 ()); } else{ List.add (New ConcreteElement2 ()); } } return list; }}
public class Client {public static void Main (string[] args) { list<element> List = Objectstruture.getlist (); for (Element e:list) { e.accept (new Visitor ());}}}
Advantages of the visitor pattern
The appropriate scenario for the visitor pattern
If there are some operations in an object that are irrelevant (or weaker) to this object, you can use the visitor pattern to encapsulate these actions to the visitor in order to avoid polluting the object.
If there is a similar operation in a set of objects, you can encapsulate the repeated actions in the visitor in order to avoid the occurrence of a large number of duplicated code.
However, the visitor pattern is not perfect, and it has a fatal flaw : Adding new element classes is more difficult. The code of the visitor pattern can see that in the visitor class, each element class has its corresponding processing method, that is, each additional element class needs to modify the visitor Class (also includes the visitor class subclass or the implementation Class), the modification is quite troublesome. in other words, the visitor pattern should be used with caution in cases where the number of element classes is uncertain. Therefore, the visitor pattern is suitable for the reconstruction of the existing function, for example, the basic function of a project has been determined, the element class data has been basically determined to not change, will change only the relevant operations within these elements, we can use the visitor pattern to reconstruct the original code again, In this way, you can modify the original functionality without modifying the individual element classes.
Summarize
As GoF , author of design mode, describes the visitor pattern: In most cases you don't need to use the visitor pattern, but when you need to use it, you really need it. Of course, this is only for the real Daniel. In real-world situations (at least in my environment), many people tend to indulge in design patterns, and when they use a design pattern, they never seriously consider whether the patterns they use are suitable for this scenario, and often just want to demonstrate their ability to harness object-oriented design. There is this mentality in programming, and abuse of design patterns often occurs. Therefore, when learning the design pattern, we must understand the applicability of the model. The need to use a pattern is to understand its merits, not to use a pattern because of its drawbacks, rather than to use a pattern because it does not understand its drawbacks, and not to use a pattern because it does not understand its merits.
(19) Visitor mode