Visitor Pattern in Scala: Mastering Behavioral Design Patterns

Visitor pattern: A behavioral pattern that separates operations from the object structure they run over, so new operations can be added without changing the element types.

Visitor matters less in Scala than in classic object-oriented languages because sealed traits and pattern matching already give you a very direct way to define operations over a fixed hierarchy. The real design question is whether the element hierarchy or the set of operations is the more stable axis.

Start With the Stability Question

If the hierarchy is closed and stable, pattern matching is usually the clearest answer:

1sealed trait Expr
2final case class Number(value: Int) extends Expr
3final case class Add(left: Expr, right: Expr) extends Expr
4
5def eval(expr: Expr): Int =
6  expr match
7    case Number(value) => value
8    case Add(left, right) => eval(left) + eval(right)

This is often better than simulating the classic visitor ceremony because the operation is explicit and the set of element types is right in front of you.

Visitor Still Helps in Specific Cases

Visitor earns its place when:

• the element hierarchy is stable but operations change frequently
• the structure is open or defined by Java interfaces you do not control
• you want to package an operation as a named object with dependencies
• you need multiple traversals or analyses over the same structure

Java interop is the most common reason. If the hierarchy is already visitor-shaped, fighting it with Scala wrappers can be more awkward than embracing the existing boundary.

Scala-Friendly Visitor Shape

A Scala-friendly visitor often looks closer to a fold than to textbook accept/visit boilerplate:

 1trait ExprVisitor[A]:
 2  def number(value: Int): A
 3  def add(left: A, right: A): A
 4
 5sealed trait Expr:
 6  def visit[A](visitor: ExprVisitor[A]): A
 7
 8final case class Number(value: Int) extends Expr:
 9  def visit[A](visitor: ExprVisitor[A]): A =
10    visitor.number(value)
11
12final case class Add(left: Expr, right: Expr) extends Expr:
13  def visit[A](visitor: ExprVisitor[A]): A =
14    visitor.add(left.visit(visitor), right.visit(visitor))

This is essentially a structured fold over the AST. The benefit is that new operations become new visitors. The cost is that new element types force visitor updates everywhere.

Visitor Versus Pattern Matching

The trade-off is simple:

• with pattern matching, adding a new element type is localized to the hierarchy but every operation may need review
• with Visitor, adding a new operation is localized, but new element types force visitor-wide change

That means Visitor is better when operations vary more often than the underlying structure.

Common Failure Modes

Recreating Visitor for Closed ADTs

Teams sometimes implement full visitor boilerplate on top of a sealed trait hierarchy where a direct pattern match would be shorter, clearer, and easier to teach.

Hiding Simple Logic Behind Visitors

One small calculation becomes a visitor object, an accept method, and a pile of indirection with no real gain.

Forgetting the Direction of Change

If new element types are added often, Visitor becomes painful because every visitor has to be extended in lockstep.

Practical Heuristics

In Scala, prefer sealed traits plus pattern matching for closed hierarchies. Use Visitor when operations truly outnumber structure changes, when you need a named operation boundary, or when Java interop makes visitor-style separation the honest design.

Knowledge Check