This is the 16th day of my participation in Gwen Challenge

Visitor pattern

The visitor pattern is a pattern that separates data operations from data structures. The basic idea of a visitor is that the system has a stable object structure of many objects that have a method to receive a visitor object. A visitor is an interface that has a method that does different things to different types of elements in the object structure it accesses.

Visitor pattern definition: Encapsulates the operations of elements that operate on certain data structures. It defines operations that operate on those elements without changing the data structure.

In actual combat

The Visitor pattern is primarily Visitor (abstract class or interface), which defines the behavior for accessing elements, with parameters as accessible element objects. In theory, visitors are consistent with the type of elements, and using the visitor pattern becomes less applicable if element classes are frequently added or deleted. Staff is an element abstraction class from which the accessed object elements inherit. The Visitor interface implements multiple subclass objects that access the Staff. The CEO and CTO are Visitor interface concrete implementation classes, respectively, and both have access to the Staff subclass object. The difference is that the operations to access the object are different. When a CEO visits Engineer, he only cares about his salary. When a CTO visits Engineer, he only cares about his development information. So that’s the visitor pattern distinction, there’s a difference in how operations are performed and that difference is distinguished by the object class, which can be interpreted as a substitution for the if-else form.

public abstract class Staff{
    public String name;
    public int salary;
    public abstract accept(Visitor visitor);
}

public interface Visitor{
    public void visitor(Engineer engineer);
    public void visitor(Manager manager);
}

public class Engineer extends Staff{

    @override
    public accept(Visitor visitor){
        visitor.visitor(this);
    }
    
    public String getDevelopInfo(a){}}public class Manager extends Staff{

    @override
    public accept(Visitor visitor){
        visitor.visitor(this);
    }
    
    public int getSalary(a){
        return salary;
    }
    
    public int getReport(a){}}public class CEO extends Visitor{
    @override
    public visitor(Engineer engineer){ engineer.getSalary(); . }@override
    public visitor(Manager manager){ manager.getReport(); . }}public class CTO extends Visitor{
    @override
    public visitor(Engineer engineer){ engineer.getDevelopInfo(); . }@override
    public visitor(Manager manager){ manager.getSalary(); . }}Copy the code

Annotation form

Annotations are also a common form of Android development. Annotations fall into two types: runtime annotations and compile-time annotations. Compiling the annotation core relies on APT, and when we process annotations through APT, we eventually convert the captured elements into the corresponding Element to retrieve their corresponding information.

// Base class of the element
public interface Element extends javax.lang.model.AnnotatedConstruct {
 
  ElementKind getKind(a);// Get the element type
   / / /...
  <R, P> R accept(ElementVisitor<R, P> v, P p);// Accept interviews from visitors
}
// Visitor ElementVisitor
public interface ElementVisitor<R.P> {
 
  R visit(Element e, P p);

  R visit(Element e);
  
  R visitPackage(PackageElement e, P p);

  R visitType(TypeElement e, P p);
 
  R visitVariable(VariableElement e, P p);
 
  R visitExecutable(ExecutableElement e, P p);

  R visitTypeParameter(TypeParameterElement e, P p);

  R visitUnknown(Element e, P p);
}
Copy the code

conclusion

The visitor pattern is rarely touched in most cases, but is very much needed when it is actually used. Before considering design patterns, consider whether the object structure is stable enough, and whether using the visitor pattern will optimize our code rather than make it more complex.

reference

  • Android Source Code Design Patterns