访问者模式 (Visitor Pattern)

访问者模式 (Visitor Pattern)

访问者模式是一种 行为型设计模式，允许在不改变元素类的前提下，向元素类添加新的操作。通过访问者模式，可以定义新的操作，而不需要修改已有的元素类。

---

原理

1. 核心思想：
   • **元素（Element）**类中不包含复杂的行为逻辑，而是通过访问者（Visitor）来操作元素。
   • 访问者模式将操作集中到一个地方，使得新功能可以添加到现有的元素对象中，而不需要修改元素类的代码。
2. 适用场景：
   • 需要对多个类型的对象执行不同的操作，且操作需要不断扩展。
   • 元素类中的操作比较复杂，访问者模式有助于将这些操作从元素类中解耦出来。
3. 参与角色：
   • Visitor（访问者接口）：
     • 声明一个访问方法，每个元素类都通过该方法接收访问者的操作。
   • ConcreteVisitor（具体访问者）：
     • 实现访问者接口，定义每个元素类对应的操作。
   • Element（元素类接口）：
     • 声明一个接受访问者的方法。
   • ConcreteElement（具体元素类）：
     • 实现接受访问者的方法。
   • ObjectStructure（对象结构）：
     • 提供元素的容器，遍历所有的元素对象，并通过访问者执行操作。

---

优点

1. 增加新的操作：
   • 通过访问者模式，可以在不修改元素类的前提下，增加新的操作。
2. 集中管理操作：
   • 操作集中在访问者类中，便于管理和扩展。
3. 扩展性强：
   • 可以很容易地扩展新的操作，符合 开闭原则。

---

缺点

1. 增加类的数量：
   • 每增加一个操作，需要新增一个访问者类，可能导致类的数量激增。
2. 难以扩展元素类：
   • 如果元素类发生变化（比如增加新的元素），需要修改访问者类，这可能导致较大的维护开销。

---

示例代码

场景描述

假设有一个关于员工薪资管理系统，有不同类型的员工（如：开发人员、销售人员、经理）。每个员工都有不同的薪资计算方式，而我们想要通过访问者模式来扩展不同的薪资计算逻辑，而不修改员工类的实现。

---

1. 定义访问者接口

// 访问者接口
public interface EmployeeVisitor {
    void visit(Developer developer);
    void visit(Salesman salesman);
    void visit(Manager manager);
}

---

2. 定义元素接口（员工）

// 元素接口
public interface Employee {
    void accept(EmployeeVisitor visitor);
}

---

3. 定义具体元素类（员工）

// 开发人员类
public class Developer implements Employee {
    private String name;
    private double salary;

    public Developer(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public String getName() {
        return name;
    }

    public double getSalary() {
        return salary;
    }

    @Override
    public void accept(EmployeeVisitor visitor) {
        visitor.visit(this);
    }
}

// 销售人员类
public class Salesman implements Employee {
    private String name;
    private double salary;

    public Salesman(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public String getName() {
        return name;
    }

    public double getSalary() {
        return salary;
    }

    @Override
    public void accept(EmployeeVisitor visitor) {
        visitor.visit(this);
    }
}

// 经理类
public class Manager implements Employee {
    private String name;
    private double salary;

    public Manager(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public String getName() {
        return name;
    }

    public double getSalary() {
        return salary;
    }

    @Override
    public void accept(EmployeeVisitor visitor) {
        visitor.visit(this);
    }
}

---

4. 定义具体访问者（薪资计算访问者）

// 具体访问者：薪资计算器
public class SalaryVisitor implements EmployeeVisitor {

    @Override
    public void visit(Developer developer) {
        double salary = developer.getSalary() * 1.1; // 开发人员有额外奖金
        System.out.println("Developer " + developer.getName() + " earns " + salary);
    }

    @Override
    public void visit(Salesman salesman) {
        double salary = salesman.getSalary() * 1.2; // 销售人员有额外提成
        System.out.println("Salesman " + salesman.getName() + " earns " + salary);
    }

    @Override
    public void visit(Manager manager) {
        double salary = manager.getSalary() * 1.3; // 经理有更高的额外补贴
        System.out.println("Manager " + manager.getName() + " earns " + salary);
    }
}

---

5. 客户端代码

public class VisitorPatternExample {
    public static void main(String[] args) {
        // 创建员工对象
        Employee developer = new Developer("Alice", 8000);
        Employee salesman = new Salesman("Bob", 5000);
        Employee manager = new Manager("Charlie", 10000);

        // 创建访问者对象
        EmployeeVisitor salaryVisitor = new SalaryVisitor();

        // 计算每个员工的薪水
        developer.accept(salaryVisitor);
        salesman.accept(salaryVisitor);
        manager.accept(salaryVisitor);
    }
}

---

输出结果

Developer Alice earns 8800.0
Salesman Bob earns 6000.0
Manager Charlie earns 13000.0

---

UML 类图

        +------------------+                    +---------------------+
        |   EmployeeVisitor | <---------------- |   ConcreteVisitor   |
        +------------------+                    +---------------------+
        | + visit()         |                    | + visit(Developer)   |
        |                  |                    | + visit(Salesman)    |
        +------------------+                    | + visit(Manager)     |
                 ^                             +---------------------+
                 |                                      ^
        +--------+--------+                +-------------+-------------+
        |        |        |                |             |             |
 +------------+  +-------------+     +--------------+   +------------+
 |   Developer |  |  Salesman  |     |   Manager    |   | Employee   |
 +------------+  +-------------+     +--------------+   +------------+
 | + accept() |  | + accept()  |     | + accept()    |   | + accept() |
 | + getName()|  | + getName() |     | + getName()   |   +------------+
 | + getSalary()| | + getSalary()|   | + getSalary() | 
 +-------------+  +-------------+     +--------------+  

---

使用场景

1. 报表生成：
   • 在不同的元素上生成不同的报表内容（如销售报表、财务报表等）。
2. 编译器设计：
   • 在编译过程中，访问不同类型的抽象语法树（AST）节点进行操作。
3. 不同操作的扩展：
   • 例如文件系统的操作、支付系统的操作等，每种操作对于不同类型的对象进行不同处理。

---

扩展与优化

1. 元素对象增加时的修改成本：

   • 如果新增元素类，需要修改所有访问者类，可能导致访问者类增多。
   • 可以通过引入 Visitor 类型的扩展机制来避免重复修改。

2. 访问者的多重功能：

   • 访问者可以扩展多种功能（如：操作A、操作B等），但每个新功能仍然需要为每个元素类型实现。

3. 适应多态：

   • 使用多态的方式管理访问者和元素对象，使得扩展更加灵活。

---

小结

• 访问者模式通过将操作分离到独立的访问者中，避免了在元素类中添加过多的业务逻辑。
• 适合有多种不同操作，需要对不同类型的元素执行相同操作的场景。
• 增加新的操作时无需修改元素类，而是通过扩展新的访问者来实现，符合开闭原则。