本文目录导读：
在某些场景下可以替代，但在复杂场景（特别是代数数据类型或需要扩展操作时）不能完全替代。
更准确地说,Java 17+ 的 sealed class + pattern matching 组合极大地削弱了访问者模式在 Java 中的必要性，但并未完全消除其价值。
下面详细对比两者的优劣,方便你判断在何种情况下可以用模式匹配替代：
核心区别：数据与操作的绑定方式
- 访问者模式 （Visitor Pattern）： 操作是侵入式的，你需要为每种新操作创建一个新的
Visitor类，并修改或扩展被访问者的结构（通常是增加一个accept方法），核心思想是“将操作从数据结构中分离出来”。 - 模式匹配 （Pattern Matching）： 操作是非侵入式的，你不需要修改数据结构本身，只需在外部使用
switch或instanceof表达式来匹配数据的“形状”，核心思想是“根据数据的类型和结构直接编写逻辑”。
何时可以用模式匹配替代访问者？
当数据结构是“封闭的”（Sealed）且操作是“有限的”时，模式匹配是更优雅、更简洁的替代方案。
典型场景： 表达式求值、状态机、简单的 AST（抽象语法树）处理。
示例对比：
数据结构： 一个简单的形状系统（Circle, Rectangle），这个类型的可能子类是固定的。
使用访问者模式（Java 8 风格）：
// 1. 定义访问者接口
interface ShapeVisitor<T> {
T visit(Circle circle);
T visit(Rectangle rect);
}
// 2. 每个形状类都要增加 accept 方法
sealed interface Shape permits Circle, Rectangle {}
final record Circle(double radius) implements Shape {
@Override public <T> T accept(ShapeVisitor<T> visitor) { return visitor.visit(this); }
}
final record Rectangle(double width, double height) implements Shape {
@Override public <T> T accept(ShapeVisitor<T> visitor) { return visitor.visit(this); }
}
// 3. 每增加一个操作，就创建一个新类
public class AreaCalculator implements ShapeVisitor<Double> {
@Override public Double visit(Circle c) { return Math.PI * c.radius() * c.radius(); }
@Override public Double visit(Rectangle r) { return r.width() * r.height(); }
}
// 使用
Shape shape = new Circle(5);
double area = shape.accept(new AreaCalculator());
使用模式匹配（Java 21+ 风格）：
// 1. 数据结构保持不变（不需要 accept 方法）
sealed interface Shape permits Circle, Rectangle {}
final record Circle(double radius) implements Shape {}
final record Rectangle(double width, double height) implements Shape {}
// 2. 操作就是一段独立的函数/方法，无需额外类
public double calculateArea(Shape shape) {
return switch (shape) {
case Circle c -> Math.PI * c.radius() * c.radius();
case Rectangle r -> r.width() * r.height();
// 编译器知道 Shape 只有这两种子类，因此无需 default 分支（如果密封且匹配完整）
};
}
模式匹配的优势：
- 代码量少： 无需定义
Visitor接口、accept方法。 - 内聚： 逻辑写在同一个地方，易于理解。
- 类型安全： 编译器会检查
switch是否覆盖了所有 sealed 子类。
何时模式匹配不能替代访问者？
当你的系统面临以下需求时,访问者模式仍然有其独特价值：
需要支持“双分派”（Double Dispatch）或复杂的方法重载
访问者模式的核心是“双分派”（Double Dispatch），当操作不仅依赖于访问者的类型，还依赖于被访问者的类型时，访问者的 visit 方法重载可以使语言自动选择正确的方法。
模式匹配是“单分派”的变体（根据具体类型匹配），但在某些动态或跨类继承链的复杂分派中，访问者的结构更清晰。
数据结构是开放的（Non-sealed）
- 访问者模式： 新增一个
Shape类型（Triangle），所有现有的Visitor接口都需要修改（增加visit(Triangle)方法），这是它的缺点，但如果你希望强制所有操作都显式处理新类型，这反而是优点。 - 模式匹配：
Shape没有声明为sealed，switch中匹配Circle和Rectangle的 case 就无法保证覆盖所有类型，必须添加default分支，这种情况下的可维护性不如访问者模式，因为类型会在你不知情的情况下被增加。
如果你无法控制数据类型的扩展（例如第三方库中的类），模式匹配无法提供一个安全的、编译时检查的方案，访问者模式可以通过修改现有 Visitor 来适配，而模式匹配只能依赖运行时的 default 分支，容易遗漏。
操作的数量远多于类型的数量
访问者模式适合操作易变、类型相对稳定的场景，当你有一个稳定的类型层级（如 GUI 控件：Button、TextField、CheckBox），但需要不断添加新操作（Serialize、Render、Print、Validate、Localize）时，访问者模式非常优雅，你可以为每个操作新增一个 Visitor 类，而无需修改控件类。
模式匹配虽然也可以实现,但如果你有 50 个操作，就需要写 50 个 switch 表达式，这些 switch 表达式通常散布在不同的类或文件中，不便于统一管理，而访问者模式可以将这些操作集中在一个包里，结构更清晰。
需要保留与旧代码的兼容性
如果你的项目还在使用 Java 8-16，或者你的团队不打算升级到 Java 21+，访问者模式是唯一可行的选项。
何时选哪个？
| 特性对比 | 访问者模式 | Sealed Class + Pattern Matching |
|---|---|---|
| 适用语言版本 | Java 5+ | Java 17+（预览），Java 21+（正式） |
| 数据结构开放性 | 适合开放结构（但增加新类型麻烦） | 需要结构封闭（sealed） |
| 操作扩展性 | 强（新增操作只需新增 Visitor 类） | 一般（新增操作需要新增 switch 函数） |
| 类型扩展性 | 弱（新增类型需要修改所有 Visitor） | 强（新增类型只需在 switch 中添加 case） |
| 代码简洁度 | 冗长、样板代码多 | 非常简洁、直接 |
| 类型安全 | 编译时检查（如访问者接口签名） | 编译时检查（sealed 类的 switch 完整性） |
| 适用场景 | 复杂框架、需要与旧代码兼容、类型开放 | 新的、小而美的领域模型、表达式、状态机 |
最终建议：
- 如果你能使用 Java 21+，并且数据类型是
sealed的（即你知道所有可能的子类），那么请用模式匹配！ 它是 Java 语言的原生特性，更现代、更简洁。 - 如果你需要在一个非常庞大、类型开放的类层次结构上定义多种操作（UI 框架的控件 + 几十种遍历、渲染、序列化操作），或者你需要与使用访问者的第三方库交互，那么访问者模式仍然是更好的选择。
- 通常的做法是： 在新项目中，优先使用
sealed class+ 模式匹配，只有当发现模式匹配确实无法优雅解决问题（如遇到上述场景二、三）时，才考虑回退到访问者模式。
