(GO) Visitor mode

Original: http://blog.csdn.net/zhengzhb/article/details/7489639

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:

[Java]View Plaincopy

2. Class A {
4. public void Method1 () {
6. System.out.println ("I am a");
8. }
12. public void Method2 (b b) {
14. B.showa (this);
16. }
18. }
22. Class B {
24. public void ShowA (a a) {
26. A.method1 ();
28. }
30. }

We mainly look at the difference between method Method1 and method Method2 in Class A, the method method1 is simple, which is to print out a phrase "I am a"; the method method2 a little more complex, uses Class B as a parameter, and invokes the Showa method of Class B. Then look at the Showa method of Class B, the Showa method uses Class A as a parameter, and then call the Method1 method of Class A, you can see that the Method2 method around to go around, nothing is called a method1 method of its own, it should also run the result should be "I am a", After the analysis, let's run through the two methods and look at the results of the operation:

[Java]View Plaincopy

1. Public class Test {
2. public static void Main (string[] args) {
3. A = new A ();
4. A.method1 ();
5. A.METHOD2 (new B ());
6. }
7. }

The result of the operation is:

I'm a.
I'm a.

Understanding This example, you understand the visitor pattern of 90%, 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: implementing the Accept method declared by the abstract element class, usually visitor.visit (this), has basically formed 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

[Java]View Plaincopy

2. Abstract class Element {
4. public abstract Void Accept (Ivisitor visitor);
6. public abstract void dosomething ();
8. }
12. Interface Ivisitor {
14. public void Visit (ConcreteElement1 el1);
16. public void Visit (ConcreteElement2 el2);
18. }
22. Class ConcreteElement1 extends Element {
24. public void DoSomething () {
26. System.out.println ("This is element 1");
28. }
32. public Void Accept (Ivisitor visitor) {
34. Visitor.visit (this);
36. }
38. }
42. Class ConcreteElement2 extends Element {
44. public void DoSomething () {
46. System.out.println ("This is Element 2");
48. }
52. public Void Accept (Ivisitor visitor) {
54. Visitor.visit (this);
56. }
58. }
60. Class Visitor implements Ivisitor {
64. public void Visit (ConcreteElement1 el1) {
66. El1.dosomething ();
68. }
72. public void Visit (ConcreteElement2 el2) {
74. El2.dosomething ();
76. }
78. }
82. Class Objectstruture {
84. public static list<element> getList () {
86. list<element> list = new arraylist<element> ();
88. Random ran = new Random ();
90. For (int i=0; i<; i++) {
92. int a = Ran.nextint (100);
94. if (a>) {
96. List.add (new ConcreteElement1 ());
98. }else{
100. List.add (new ConcreteElement2 ());
102. }
104. }
106. return list;
108. }
110. }
114. Public class Client {
116. public static void Main (string[] args) {
118. list<element> list = Objectstruture.getlist ();
120. For (Element e:list) {
122. E.accept (new Visitor ());
124. }
126. }
128. }

Advantages of the visitor pattern

• In accordance with the principle of single responsibility: in any scenario where the visitor pattern is applied, the action that needs to be encapsulated in the visitor in the element class must be an operation that is not relevant and variable to the element class itself, and the use of the visitor pattern on the one hand conforms to the single principle of responsibility, on the other hand, because the encapsulated operation is usually variable , so when the change occurs, we can realize the expansion of the changing part without changing the element class itself.
• Good Extensibility: element classes can be extended to different operations by accepting different audiences.

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, so that, 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 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.

(GO) Visitor mode