深入探讨行为模式：访问者设计模式及其在复杂对象结构中的应用

什么是访问者设计模式？

访问者模式是一种行为设计模式，它允许你在不修改对象本身的情况下，为某一类对象定义新的操作。

这里的关键词是“行为”。行为设计模式关注的是对象之间如何进行通信以及责任是如何分配的。与创建型设计模式关注对象的创建方式不同，结构型设计模式关注对象之间的组合关系，而行为设计模式则关注对象之间的交互方式以及谁应该负责执行哪些操作。

访问者模式专门用于解决这样一个问题：当某个操作需要在多种类型的对象上执行不同的逻辑时，应该由哪个对象来负责这个操作呢？

传统的解决方法是在每个对象上都添加相应的操作方法，让每个类都拥有处理自己类型对象的操作功能。但这种方法一旦遇到多个操作需求，就会变得不可行，因为每次新增一个操作，就意味着需要修改所有的相关类。这种做法会导致整个代码结构变得极其复杂。

访问者模式恰恰改变了这种处理方式。它并没有将各种操作分散到各个对象中，而是将这些操作集中到一个被称为“访问者”的组件中。各个对象只需接受这个访问者，并让它完成自己的工作即可。每当需要添加新的操作时，就只需要创建一个新的访问者组件而已，现有的对象本身根本不需要发生任何变化。

这正是“开闭原则”所期望发挥的作用：允许扩展，但禁止修改。

访问者模式所要解决的问题

让我来具体说明一下，如果没有使用访问者模式，会是什么情况。

假设你有一个金融科技平台，平台上有多种类型的用户：现有客户、新客户、未成年账户持有者以及联名账户持有者。你的产品经理要求为你们的产品添加文档导出功能，而且每种类型的用户都应该能够将文档导出为PDF、Excel或CSV格式。

如果不使用访问者模式，那么实现这个功能的自然方式会是这样的：

class ExistingUser {
  final int id;
  final String firstName;
  final String lastName;
  final DateTime lastPaymentDate;
  final num accountBalance;

  String exportToPdf() {
    return '$firstName\n$lastName\n$lastPaymentDate\n$accountBalance';
  }

  String exportToExcel() {
    return '$firstName,$lastName,$lastPaymentDate,$accountBalance';
  }

  String exportToCsv() {
    return '"$firstName","$lastName","$lastPaymentDate","$accountBalance"';
  }
}

对于新客户、未成年账户持有者以及联名账户持有者，也需要分别编写类似的代码。就这样，仅仅为了实现文档导出功能，就有十二个方法分散在四个不同的类中。

后来产品经理又提出了新的需求：需要为用户提供电子邮件通知、短信通知以及推送通知功能。于是你又不得不再次修改这四个类，每个类都需要增加三个新的方法。这样一来，同样的四个类中又增加了十二个方法。

随后他们还要求实现费用计算功能以及进行客户身份验证状态检查。每当有新的功能需求出现时，这些操作都会应用到所有类型的用户身上。因此，相关类的数量不断增加，需要修改的地方也越来越多，测试工作也变得极其繁琐。

而这恰恰就是访问者模式被设计出来所要解决的问题。

核心组件

访问者模式由四个核心组件构成。在查看代码之前先了解这些组件的功能，会让你更容易理解整个模式的实现原理。

访问者接口

这是所有访问者组件都必须实现的契约。它规定了针对每种需要被访问的对象类型，都需要定义一个相应的方法。例如，如果一个访问者组件需要处理四种类型的用户，那么它就需要定义四个方法，分别对应这四种类型。

具体实现类

这些就是访问者接口的具体实现类。每个实现类都负责执行某一项具体的操作，并且知道如何处理所有类型的对象。例如， PdfHandler就是一个具体实现类，ExcelHandler也是一个具体实现类，SmsNotificationHandler同样如此。每一个实现类都有其特定的职责，并且能够为所有类型的用户完成相应的操作。

消费者接口（也称为元素或接受者接口）

这是层次结构中每个对象都必须实现的接口。该接口定义了一个名为`accept`的方法，该方法接收一个`Visitor`对象，并调用相应的访问方法来处理该对象。正是这种“双重调度机制”使得这一设计模式能够正常运作。

具体消费者对象

这些才是层次结构中的实际对象：`ExistingCustomers`、`NewCustomers`、`MinorCustomer`和`JointCustomer`。每一个这类对象都会通过调用与其自身类型相匹配的访问方法来实现`accept`接口。

可以这样理解：`Visitor`接口被所有需要执行特定操作的类所实现，比如`PdfHandler`、`ExcelHandler`和`CsvHandler`；这些类都知道如何处理这四种类型的用户对象。

而`Consumer`接口则被层次结构中的每一个对象所实现，包括`ExistingCustomers`、`NewCustomers`、`MinorCustomer`和`JointCustomer`；它们都知道如何接收`Visitor`对象，并将其转发到正确的处理方法中。

当你调用`existingCustomer.accept(pdfHandler)`时，`ExistingCustomers`会自动调用`pdfHandler.visitExistingCustomer(this)`，并将自身作为参数传递给该方法。正确的处理方法会自动被执行，整个过程中不需要进行类型检查、条件判断或switch语句操作。对象只需告诉访问者自己的身份，访问者就会知道该如何利用这些信息来完成任务。

现实世界案例一：文档导出

这是一个来自金融科技平台的真实场景：系统中存在四种类型的用户，它们具有不同的数据结构，但都需要将自身的信息导出为PDF、Excel和CSV三种格式。

步骤1：定义用户模型

class ExistingUser {
  final int id;
  final String firstName;
  final String lastName;
  final DateTime lastPaymentDate;
  final num accountBalance;

  const ExistingUser({
    required this.id,
    required this.firstName,
    required this.lastName,
    required this.lastPaymentDate,
    required this.accountBalance,
  });
}

class NewUser {
  final String firstName;
  final String lastName;

  const NewUser({
    required this.firstName,
    required this.lastName,
  });
}

class MinorAccountUser {
  final int age;
  final int guardianId;
  final String firstName;
  final String lastName;
  final String guardianName;

  const MinorAccountUser({
    required this.age,
    required this.guardianId,
    required this.firstName,
    required this.lastName,
    required this.guardianName,
  });
}

class JointAccountUser {
  final int jointAccountId;
  final List accountHoldersInfo;
  final num accountBalance;

  const JointAccountUser({
    required this.jointAccountId,
    required this.accountHoldersInfo,
    required this.accountBalance,
  });
}

我们这里定义了四种用户模型，每种模型只包含自身所需的数据，不包含任何导出逻辑或通知机制，也不涉及任何业务操作。这些仅仅是纯粹的数据结构而已。

正是应该这样。模型的作用就是存储数据，而访问者的职责则是对这些数据进行处理。

步骤2：定义访问者与消费者接口

abstract class UserVisitor {
  T visitExistingCustomer(ExistingUser user);
  T visitNewCustomer(NewUser user);
  T visitMinorCustomer(MinorAccountUser user);
  T visitJointCustomer(JointAccountUser user);
}

abstract class UserConsumer {
  T accept(UserVisitor visitor);
}

UserVisitor是一个泛型类。类型参数T表示访问者方法返回的值类型：文档导出功能对应的访问者会返回一个字符串，费用计算功能对应的访问者可能会返回一个双精度浮点数，验证功能对应的访问者则可能返回一个布尔值。任何类型的返回值都可以使用这种模式。

UserConsumer类定义了accept方法。层次结构中的每一个对象都必须实现这个方法。正是accept方法使得双 dispatch机制能够正常工作——对象接收访问者对象后，会立即调用相应的方法，并将自己作为参数传递给该方法。

步骤3：实现具体的消费者类

class ExistingCustomers implements UserConsumer {
  final ExistingUser user;
  ExistingCustomers({required this.user});

  @override
  T accept(UserVisitor visitor) {
    return visitor.visitExistingCustomer(user);
  }
}

class NewCustomers implements UserConsumer {
  final NewUser user;
  NewCustomers({required this.user});

  @override
  T accept(UserVisitor visitor) {
    return visitor.visitNewCustomer(user);
  }
}

class MinorCustomer implements UserConsumer {
  final MinorAccountUser user;
  MinorCustomer({required this.user});

  @override
  T accept(UserVisitor visitor) {
    return visitor.visitMinorCustomer(user);
  }
}

class JointCustomer implements UserConsumer {
  final JointAccountUser user;
  JointCustomer({required this.user});

  @override
  T accept(UserVisitor visitor) {
    return visitor.visitJointCustomer(user);
  }
}

每个消费者类都负责处理某种类型的用户数据，并通过调用相应的访问者方法来完成自己的功能。具体来说，这些消费者类会判断自己所处理的用户类型是什么，然后通过调用正确的访问者方法来执行相应的操作。

需要注意的是，这些类中没有任何一个与PDF、Excel、CSV、电子邮件、短信或任何具体的数据处理操作有关联。它们完全独立于将来可能对这些数据进行的各种操作。

步骤4：实现具体的访问者类

class PdfHandler implements UserVisitor {
  @override
  String visitExistingCustomer(ExistingUser user) {
    return '${user.firstName} ${user.lastName}'
        '\n余额: ${user.accountBalance}'
        '\n最后一次付款日期: ${user.lastPaymentDate}`;
  }

  @override
  String visitNewCustomer(NewUser user) {
    return '${user.firstName} ${user.lastName)';
  }

  @override
  String visitMinorCustomer(MinorAccountUser user) {
    return '${user.firstName} ${user.lastName}'
        '\n年龄: ${user.age}'
        '\n监护人: ${user.guardianName} (ID: ${user.guardianId})';
  }

  @override
  String visitJointCustomer(JointAccountUser user) {
    final holders = user.accountHoldersInfo.join(', ');
    return '联合账户编号: ${user.jointAccountId}'
        '\n账户持有人: $holders'
        '\n余额: ${user.accountBalance}`;
  }
}

class ExcelHandler implements UserVisitor {
  @override
  String visitExistingCustomer(ExistingUser user) {
    return '${user.firstName}\t${user.lastName}'
        '\t${user.accountBalance}\t${user.lastPaymentDate)';
  }

  @override
  String visitNewCustomer(NewUser user) {
    return '${user.firstName}\t${user.lastName}`;
  }

  @override
  String visitMinorCustomer(MinorAccountUser user) {
    return '${user.firstName}\t${user.lastName}'
        '\t${user.age}\t${user.guardianName}\t${user.guardianId)';
  }

  @override
  String visitJointCustomer(JointAccountUser user) {
    final holders = user.accountHoldersInfo.join('\t');
    return '${user.jointAccountId}\t$holders\t${user.accountBalance}`;
  }
}

class CsvHandler implements UserVisitor {
  @override
  String visitExistingCustomer(ExistingUser user) {
    return '"${user.firstName}","${user.lastName}"'
        ',"${user.accountBalance}","${user.lastPaymentDate}"';
  }

  @override
  String visitNewCustomer(NewUser user) {
    return '"${user.firstName}","${user.lastName}"';
  }

  @override
  String visitMinorCustomer(MinorAccountUser user) {
    return '"${user.firstName}","${user.lastName}"'
        ',"${user.age}","${user.guardianName}","${user.guardianId}"';
  }

  @override
  String visitJointCustomer(JointAccountUser user) {
    final holders = user.accountHoldersInfo.map((h) => '"$h"').join(',');
    return '"${user.jointAccountId}",$holders,"${user.accountBalance}"';
  }
}

步骤5：实际应用

实际应用案例二：通知系统

如果没有“访问者模式”，这种逻辑会分散到所有四个用户模型中，或者凝聚成一个充满类型检查的庞大函数。而使用“访问者模式”后，这些逻辑被集中到了三个专门的类中。

通知访问者接口

abstract class NotificationVisitor {
  void visitExistingCustomer(ExistingUser user);
  void visitNewCustomer(NewUser user);
  void visitMinorCustomer(MinorAccountUser user);
  void visitJointCustomer(JointAccountUser user);
}

这些访问者方法返回的是`void`，因为通知本质上只是副作用——它们用于发送消息，并不返回任何值。

具体的通知访问者实现

class EmailNotificationHandler implements NotificationVisitor {
  @override
  void visitExistingCustomer(ExistingUser user) {
    print('正在给现有客户发送电子邮件：${user.firstName}`);
    // 使用用户的完整账户信息发送邮件
  }

  @override
  void visitNewCustomer(NewUser user) {
    print('正在给新客户发送欢迎邮件：${user.firstName}`);
    // 发送包含入门指南的欢迎邮件
  }

  @override
  void visitMinorCustomer(MinorAccountUser user) {
    print('正在给未成年用户的监护人发送电子邮件：${user.guardianName}`);
    // 邮件会发送给监护人的注册号码
  }

  @override
  void visitJointCustomer(JointAccountUser user) {
    for (final holder in user.accountHoldersInfo) {
      print('正在给联合账户的持有者发送电子邮件：$holder');
      // 所有账户持有者都会收到通知
    }
  }
}

class SmsNotificationHandler implements NotificationVisitor {
  @override
  void visitExistingCustomer(ExistingUser user) {
    print('正在给现有客户发送短信：${user.firstName}`);
  }

  @override
  void visitNewCustomer(NewUser user) {
    // 新用户尚未完成短信验证，跳过此步骤
    print('新客户${user.firstName}尚未符合短信通知条件');
  }

  @override
  void visitMinorCustomer(MinorAccountUser user) {
    print('正在给未成年用户的监护人${user.guardianName}发送短信：${user.firstName}`);
    // 邮件会发送到监护人的注册号码
  }

  @override
  void visitJointCustomer(JointAccountUser user) {
    for (final holder in user.accountHoldersInfo) {
      print('正在给联合账户的持有者发送短信：$holder');
    }
  }
}

class PushNotificationHandler implements NotificationVisitor {
  @override
  void visitExistingCustomer(ExistingUser user) {
    print('正在给现有客户发送推送通知：${user.firstName}`);
  }

  @override
  void visitNewCustomer(NewUser user) {
    print('正在给新客户发送推送通知：${user.firstName}`);
  }

  @override
  void visitMinorCustomer(MinorAccountUser user) {
    // 未成年用户尚未安装相关应用，因此通知会发送给监护人
    print('正在给未成年用户的监护人${user.guardianName}发送推送通知：${user.firstName}`);
  }

  @override
  void visitJointCustomer(JointAccountUser user) {
    for (final holder in user.accountHoldersInfo) {
      print('正在给联合账户的持有者发送推送通知：$holder');
    }
  }
}

使用通知处理类

void notifyExistingUser() {
  final customer = ExistingCustomers(
    user: ExistingUser(
      id: 10,
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
      lastPaymentDate: DateTime.now(),
      accountBalance: 7373773.39,
    ),
  );

  customer.accept(EmailNotificationHandler());
  customer.accept(SmsNotificationHandler());
  customer.accept(PushNotificationHandler());
}

void notifyMinorUser() {
  final customer = MinorCustomer(
    user: MinorAccountUser(
      age: 15,
      guardianId: 82882,
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
      guardianName: 'Inioluwa',
    ),
  );

  // 三个通知渠道都会被触发，且每个渠道都遵循针对未成年用户的特定规则
  customer.accept(EmailNotificationHandler());
  customer.accept(SmsNotificationHandler());
  customer.accept(PushNotificationHandler());
}

void notifyJointUser() {
  final customer = JointCustomer(
    user: JointAccountUser(
      jointAccountId: 92,
      accountHoldersInfo: [
        'Oluwaseyi',
        'Aderonke',
        'Inioluwa',
        'Tiwaloluwa',
      ],
      accountBalance: 9200020202.22,
    ),
  );

  customer.accept(EmailNotificationHandler());
  customer.accept(SmsNotificationHandler());
  customer.accept(PushNotificationHandler());
}

现实世界案例三：费用计算

费用计算接口

abstract class FeeVisitor {
  double visitExistingCustomer(ExistingUser user);
  double visitNewCustomer(NewUser user);
  double visitMinorCustomer(MinorAccountUser user);
  double visitJointCustomer(JointAccountUser user);
}

这个接口返回一个双精度数值，因为费用计算的结果本身就是数字形式。

具体的费用计算实现

class MonthlyFeeCalculator implements FeeVisitor {
  @override
  double visitExistingCustomer(ExistingUser user) {
    // 账户余额的0.5%，最低为500，最高为5000
    final fee = user.accountBalance * 0.005;
    return fee.clamp(500, 5000).toDouble();
  }

  @override
  double visitNewCustomer(NewUser user) {
    // 新客户在前三个月内免收费用
    return 0.0;
  }

  @override
  double visitMinorCustomer(MinorAccountUser user) {
    // 小账户的费用为固定金额
    return 150.0;
  }

  @override
  double visitJointCustomer(JointAccountUser user) {
    // 费用由所有账户持有人平分
    const standardFee = 2000.0;
    return standardFee / user.accountHoldersInfo.length;
  }
}

每种用户类型的费用规则都存储在这个类中。当现有客户的费用标准发生变化时，只需要修改这个类中的某个方法即可；小账户的费用调整也是如此。所有的用户模型都不会发生任何变化，其他相关的计算接口也不需要做任何修改。

使用费用计算接口

void calculateFees() {
  final existingCustomer = ExistingCustomers(
    user: ExistingUser(
      id: 10,
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
      lastPaymentDate: DateTime.now(),
      accountBalance: 7373773.39,
    ),
  );

  final newCustomer = NewCustomers(
    user: NewUser(
      firstName: 'Aderonke',
      lastName: 'Fatunmole',
    ),
  );

  final minorCustomer = MinorAccountUser(
    user: MinorAccountUser(
      age: 15,
      guardianId: 82882,
      firstName: 'Inioluwa',
      lastName: 'Fatunmole',
      guardianName: 'Oluwaseyi',
    ),
  );

  final jointCustomer = JointAccountUser(
    user: JointAccountUser(
      jointAccountId: 92,
      accountHoldersInfo: [
        'Oluwaseyi',
        'Aderonke',
        'Inioluwa',
        'Tiwaloluwa',
      ],
      accountBalance: 9200020202.22,
    ),
  );

  final calculator = MonthlyFeeCalculator();

  final existingFee = existingCustomer.accept(calculator);
  final newFee = newCustomer.accept(calculator);
  final minorFee = minorCustomer.accept(calculator);
  final jointFee = jointCustomer.accept(calculator);

  print('现有客户的费用：NGN $existingFee');
  print('新客户的费用：NGN $newFee');
  print('小账户的费用：NGN $minorFee';
  print('联合账户中每位持有人的费用：NGN $jointFee');
}

输出结果如下：

现有客户费用：5000奈拉  
新客户费用：0奈拉  
小账户费用：150奈拉  
联名账户每位持有者的费用：500奈拉

当需要为新的客户群体设计PremiumFeeCalculator时，只需创建一个实现FeeVisitor的新类即可。用户模型保持不变，MonthlyFeeCalculator也依然照旧，所有四个消费者的接受方法也都没有任何变化。

结合三种操作的力量

正是在这样的系统中，访问者模式才真正发挥了它的作用。你有相同的四种用户类型，可以在同一个调用链中对它们中的任意一种应用任意组合的访问者操作。

void processUser(UserConsumer customer) {
  final pdf = customer.accept(PdfHandler());
  final csv = customer.accept(CsvHandler());

  customer.accept(EmailNotificationHandler());
  customer.accept(PushNotificationHandler());

  final fee = customer.accept(MonthlyFeeCalculator());

  print('费用：$fee奈拉');
  print('文档已生成，通知也已发送');
}

一个函数，任意类型的用户，任意组合的操作。消费者并不关心自己会收到哪些访问者操作；访问者也不关心是哪些消费者调用了它们。它们通过接口进行交互，而这个接口能确保所有操作都能正确执行。

我们有三种完全不同的操作（文档导出、通知发送和费用计算），但它们都是通过对同一个对象应用相同的调用模式来完成的。这些操作彼此之间互不知情，也不会修改用户模型。每种操作都存在于自己独立的类中，且每个类都有其独特的存在目的。

何时使用访问者模式

当你拥有一组稳定的对象类型以及针对这些类型的不断增多的操作时，就可以使用访问者模式。