设计模式——访问者设计模式（行为型）

摘要

访问者设计模式是一种行为型设计模式，它将数据结构与作用于结构上的操作解耦，允许在不修改数据结构的前提下增加新的操作行为。该模式包含关键角色如元素接口、具体元素类、访问者接口和具体访问者类。通过访问者模式，可以在不改变对象结构的情况下，定义新的操作行为。文章通过示例场景和类图、时序图等详细介绍了访问者设计模式的结构和实现方式，并探讨了其适用场景和实战示例。

1. 访问者设计模式定义

将数据结构与作用于结构上的操作解耦，使得在不修改数据结构的前提下，可以增加新的操作行为。访问者模式允许你在不改变对象结构（如树、图、元素集合）的前提下，定义新的操作行为，通过将这些操作封装到独立的 "访问者" 对象中。

1.1. 关键角色说明

角色	说明
`Element`	定义 `accept(Visitor)`接口，让访问者访问自己。
`ConcreteElement`	实现 `Element`接口，实现接受访问者的具体逻辑。
`Visitor`	抽象访问者，定义访问每个元素的接口 `visit(ElementA)`等。
`ConcreteVisitor`	实现 `Visitor`，封装对元素结构的具体操作，比如导出、统计、渲染等行为。

1.2. 示例场景（通俗类比）

假设你有一个对象结构为：公司组织结构，每个节点可以是员工、部门。你希望在不修改员工、部门类的前提下，分别实现：

统计薪资总额
导出组织结构为 HTML
打印汇报关系图

通过访问者模式，你可以创建多个 ConcreteVisitor 来实现上述功能，而无需改动 Element 本身代码。

2. 访问者设计模式结构

访问者 （Visitor）接口声明了一系列以对象结构的具体元素为参数的访问者方法。如果编程语言支持重载，这些方法的名称可以是相同的，但是其参数一定是不同的。
具体访问者 （Concrete Visitor）会为不同的具体元素类实现相同行为的几个不同版本。
元素（Element）接口声明了一个方法来 “接收” 访问者。该方法必须有一个参数被声明为访问者接口类型。
具体元素 （Concrete Element）必须实现接收方法。该方法的目的是根据当前元素类将其调用重定向到相应访问者的方法。请注意，即使元素基类实现了该方法，所有子类都必须对其进行重写并调用访问者对象中的合适方法。
客户端 （Client）通常会作为集合或其他复杂对象（例如一个组合(opens new window)树）的代表。客户端通常不知晓所有的具体元素类，因为它们会通过抽象接口与集合中的对象进行交互。

2.1. 访问者设计模式类图

2.2. 访问者设计模式时序图

3. 访问者设计模式实现方式

访问者设计模式的实现方式，核心在于：将作用于对象结构的操作行为封装到独立的访问者类中，并通过 accept(Visitor) 方法把访问者“注入”到元素中，从而实现对结构中不同元素的不同处理。

3.1. 步骤 1：定义元素接口 `Element`

public interface Element {
    void accept(Visitor visitor);
}

3.2. 步骤 2：实现具体元素类（ConcreteElement）

public class Employee implements Element {
    private String name;
    private double salary;

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

    // 提供访问者访问自己
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }

    // getter
    public String getName() { return name; }
    public double getSalary() { return salary; }
}

public class Department implements Element {
    private String deptName;

    public Department(String deptName) {
        this.deptName = deptName;
    }

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

    public String getDeptName() { return deptName; }
}

3.3. 步骤 3：定义访问者接口 `Visitor`

public interface Visitor {
    void visit(Employee employee);
    void visit(Department department);
}

3.4. 步骤 4：实现具体访问者（ConcreteVisitor）

public class ReportVisitor implements Visitor {
    @Override
    public void visit(Employee employee) {
        System.out.println("员工：" + employee.getName() + "，薪资：" + employee.getSalary());
    }

    @Override
    public void visit(Department department) {
        System.out.println("部门：" + department.getDeptName());
    }
}

3.5. 步骤 5：使用访问者

public class Client {
    public static void main(String[] args) {
        List<Element> elements = Arrays.asList(
            new Employee("张三", 12000),
            new Employee("李四", 15000),
            new Department("风控部")
        );

        Visitor visitor = new ReportVisitor();

        for (Element element : elements) {
            element.accept(visitor);  // 每个元素调用 visitor.visit(this)
        }
    }
}

3.6. 说明总结

点位	描述
解耦操作和结构	不改动 Element 的结构代码，就能添加任意多种访问逻辑。
遵循开闭原则	新增操作时，只需新建访问者类即可。
单一职责更清晰	每个访问者只关注自己的行为。
缺点：扩展结构麻烦	每次新增 Element 子类，所有 `Visitor`都要加新的 `visit()` 方法。

4. 访问者设计模式适合场景

以下是访问者（Visitor）设计模式适合与不适合使用的场景清单，便于你快速判断在实战开发中是否应当使用此模式。

4.1. ✅ 适合使用访问者设计模式的场景

场景	说明
✅ 需要对对象结构中不同元素进行不同操作	如处理复杂对象树时，不同节点类型需要不同处理（如 AST 抽象语法树、HTML DOM、组织结构等）。
✅ 需要在不修改类的前提下增加新操作	元素类稳定，但经常添加新功能，适合将操作逻辑外移成访问者类。符合开闭原则。
✅ 多个操作跨多个类共享处理逻辑	如统计报表、导出功能、数据校验，每种功能可封装为访问者，避免元素类职责膨胀。
✅ 数据结构较复杂，逻辑需要分离	尤其在组合模式（Composite）中遍历树状结构时，访问者是理想搭档。
✅ 需要记录访问轨迹/数据收集/行为链式执行	访问者可收集上下文数据，实现功能链、审计等操作。

4.2. ❌ 不适合使用访问者设计模式的场景

场景	原因
❌ 对象结构不稳定，经常增删元素类型	每新增一个元素类，所有访问者都必须修改，违反开闭原则，维护成本高。
❌ 操作种类少，变化不频繁	如果只有一两种操作，直接放到元素类中即可，访问者反而引入了额外复杂性。
❌ 操作需要频繁访问元素内部状态/私有字段	访问者访问元素的内部字段时会暴露实现细节，可能破坏封装性。
❌ 数据驱动而非行为驱动系统	如果处理逻辑更多是对数据表进行规则驱动处理，不如使用策略模式、责任链、状态机等。
❌ 系统对性能极度敏感，层层函数调用不可接受	访问者调用链过长，对性能要求极高的系统中不推荐使用。

4.3. ✅ 实战使用建议

建议点	内容
👍 推荐与组合模式搭配使用	树形结构遍历 + 多种处理逻辑，非常适合访问者模式。
👍 可与责任链、模板方法组合	在访问者中执行链式操作或分步骤逻辑。
⚠️ 避免与频繁变更的领域模型搭配	如果业务模型变化频繁，访问者维护成本非常高。

5. 访问者设计模式实战示例

以下是一个基于访问者设计模式的 Spring 项目实战示例，应用于金融风控场景，使用注解方式注入对象，涵盖了完整的结构。

金融风控中，需要对不同类型的用户（例如：个人、企业）进行多维度风险评估，比如信用评分、交易行为分析、黑名单检查等。不同用户类型暴露的数据结构不同，但我们希望将“风险评估逻辑”从数据结构中解耦出来。

使用访问者模式可实现：

新增风险评估逻辑（访问者）无需修改用户结构；
用户数据结构与评估操作解耦，符合开闭原则。

5.1. 📦 项目结构

risk-visitor
├── model
│   ├── User.java
│   ├── PersonalUser.java
│   └── CompanyUser.java
├── visitor
│   ├── RiskVisitor.java
│   ├── CreditScoreVisitor.java
│   └── FraudCheckVisitor.java
├── config
│   └── VisitorConfig.java
└── RiskEvaluationService.java

5.2. 用户对象层（Element）

public interface User {
    void accept(RiskVisitor visitor);
}

@Data
public class PersonalUser implements User {
    private String name;
    private String idCard;
    private int creditScore;

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

@Data
public class CompanyUser implements User {
    private String companyName;
    private String licenseNumber;
    private double registeredCapital;

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

5.3. 风控访问者接口与实现

public interface RiskVisitor {
    void visit(PersonalUser personalUser);
    void visit(CompanyUser companyUser);
}

5.3.1. 信用评分访问者

@Component
public class CreditScoreVisitor implements RiskVisitor {

    @Override
    public void visit(PersonalUser personalUser) {
        System.out.println("[信用评分] 用户 " + personalUser.getName() + " 分数: " + personalUser.getCreditScore());
    }

    @Override
    public void visit(CompanyUser companyUser) {
        System.out.println("[信用评分] 公司 " + companyUser.getCompanyName() + " 注册资本: " + companyUser.getRegisteredCapital());
    }
}

5.3.2. 欺诈检测访问者

@Component
public class FraudCheckVisitor implements RiskVisitor {

    @Override
    public void visit(PersonalUser personalUser) {
        System.out.println("[欺诈检查] 检查身份证是否黑名单：" + personalUser.getIdCard());
    }

    @Override
    public void visit(CompanyUser companyUser) {
        System.out.println("[欺诈检查] 检查营业执照是否异常：" + companyUser.getLicenseNumber());
    }
}

5.4. 风控服务类（注解注入访问者）

@Service
public class RiskEvaluationService {

    private final List<RiskVisitor> visitors;

    @Autowired
    public RiskEvaluationService(List<RiskVisitor> visitors) {
        this.visitors = visitors;
    }

    public void evaluate(User user) {
        for (RiskVisitor visitor : visitors) {
            user.accept(visitor);
        }
    }
}

5.5. 启动与使用

@SpringBootApplication
public class RiskApp implements CommandLineRunner {

    @Autowired
    private RiskEvaluationService evaluationService;

    @Override
    public void run(String... args) {
        PersonalUser personalUser = new PersonalUser();
        personalUser.setName("张三");
        personalUser.setIdCard("123456789");
        personalUser.setCreditScore(750);

        CompanyUser companyUser = new CompanyUser();
        companyUser.setCompanyName("风控科技");
        companyUser.setLicenseNumber("XYZ-2025");
        companyUser.setRegisteredCapital(5000_000);

        evaluationService.evaluate(personalUser);
        evaluationService.evaluate(companyUser);
    }

    public static void main(String[] args) {
        SpringApplication.run(RiskApp.class, args);
    }
}

5.6. ✅ 总结优点

易于扩展新评估策略，无需改动用户结构；
Spring 自动注入访问者集合，灵活组合；
清晰分离了数据结构与操作行为。

6. 访问者设计模式思考

访问者设计模式（Visitor Pattern）在实际开发中常常与其他设计模式组合使用，以增强系统的可扩展性、解耦能力和灵活性。下面列出访问者模式常与哪些设计模式组合使用，以及各组合的典型应用场景和优势。

6.1. ✅ 访问者模式常用组合设计模式

组合模式	组合目的/优势	应用场景示例
组合模式（Composite）	用于遍历和访问复杂对象结构，访问者可递归处理整个树形结构	文档结构、组织架构、产品分类树等
迭代器模式（Iterator）	统一遍历容器结构，配合访问者实现对集合中元素的操作（如批量处理）	批量风控评估、设备监控列表操作
责任链模式（Chain of Responsibility）	多个访问者对象串联处理，解耦多个处理逻辑，每个访问者判断是否处理	多规则风控审批流程，每个处理节点负责一类校验
模板方法模式（Template Method）	访问者中封装处理通用流程，将子类特定行为抽象为钩子方法	通用风险评估框架，子类定义评分规则
策略模式（Strategy）	将访问者作为策略进行注入或切换，使不同访问行为可配置化	不同国家/行业的风险评估策略
状态模式（State）	被访问对象的状态决定了访问者逻辑流程，用于基于状态执行不同操作	用户行为轨迹、风控状态迁移等
工厂模式（Factory）	访问者工厂根据上下文动态创建访问者对象，适配不同对象结构或执行策略	动态风控策略调度系统，按对象类型或场景创建访问者
观察者模式（Observer）	访问者中执行完后通知监听者，适用于监控、日志、审计等异步行为	风控决策日志记录、报警事件触发