访问者模式(Visitor)与责任链模式(Chain of Responsibility)的核心差异是什么？

Great question! These two patterns are easy to mix up at first glance since they both involve passing things between objects, but their core purposes and mechanics are night and day. Let me break this down for you clearly:

1. Their Core Goals Are Polar Opposite #

• Visitor Pattern: At its heart, it’s about separating data structures from the operations performed on them. Imagine you have a bunch of different shape objects—circles, squares, triangles—and you want to add new features like "calculate area" or "render to SVG" without touching the shape classes themselves. The visitor pattern lets you wrap these operations into a "visitor" class. Each shape then accepts the visitor and passes itself to it, letting the visitor handle the work. The key here is extending operations without modifying existing object code.
• Chain of Responsibility Pattern: This is all about passing a request along a chain of handlers until one can process it. Think of submitting an expense report: first it goes to your department manager. If the amount is over their approval limit, it gets sent to the director, and if that’s still too high, it goes to the CEO. Each handler only cares about requests it can deal with; if it can’t, it passes the request down the line. The focus here is decoupling the request sender from the receiver, so multiple objects get a shot at handling the request.

2. How They Execute Is Totally Different #

• Visitor Pattern: It’s actively triggered and directed. You know exactly which visitor you want to use with which objects, and each object calls the visitor’s corresponding method immediately. For example, you create an AreaCalculatorVisitor, loop through all your shapes, and call shape.accept(visitor)—the visitor processes the shape right then and there. The flow is fixed and predictable.
• Chain of Responsibility Pattern: It’s passively passed with an uncertain endpoint. When you send a request, you don’t know which handler will end up processing it. Heck, maybe no handler in the chain can process it (you’d usually have a fallback for that). The chain can be reordered, handlers added or removed on the fly—this flow is dynamic, not set in stone.

3. Use Cases Are Worlds Apart #

• Reach for the Visitor Pattern when you have a fixed set of object types and need to add multiple new operations without cluttering the objects’ code. A classic example is a compiler’s abstract syntax tree: you need to run code checks, generate bytecode, and perform optimizations—all without changing the tree node classes.
• Go with the Chain of Responsibility Pattern when you want multiple objects to have a chance to handle a single request, and you don’t want the request sender to know exactly who’s handling it. Web framework middleware (like authentication, logging, request parsing) or permission check workflows are perfect examples here.

4. Their Code Structures Reflect Their Goals #

• Visitor Pattern requires your objects to have an accept method that takes a visitor, and the visitor must have a visit method for each object type. For example (in Java):

  // Shape interface with accept method
  interface Shape {
      void accept(ShapeVisitor visitor);
  }
  
  // Visitor interface with visit methods for each shape type
  interface ShapeVisitor {
      void visit(Circle circle);
      void visit(Square square);
  }
  

• Chain of Responsibility Pattern has each handler hold a reference to the next handler in the chain, plus a handleRequest method. Example:

  abstract class ApprovalHandler {
      protected ApprovalHandler nextHandler;
  
      public void setNextHandler(ApprovalHandler next) {
          this.nextHandler = next;
      }
  
      public abstract void handleExpense(ExpenseRequest request);
  }
  

内容的提问来源于stack exchange，提问作者molamola