visitor

name	visitor
description	Apply, review, or refactor code using the Visitor design pattern. Use this skill when the problem matches the pattern's structural forces, especially in Kotlin/JVM backend systems. Do not force the pattern when a simpler language or framework feature is sufficient.

Visitor

Objective

Add operations to a stable object structure without modifying the element classes.

Trigger conditions

Use this skill when at least two of these signals are present:

• The element hierarchy is stable but new operations are added frequently.
• An operation depends on concrete element types.
• Double dispatch is required.

Do not select the pattern from its name alone. First identify the design forces, the axis of change, the ownership of state, and the required lifecycle.

Do not use when

• New element types are added frequently.
• A sealed hierarchy with an exhaustive when is simpler.
• The visitor needs privileged access that breaks encapsulation.

Canonical participants

Visitor, ConcreteVisitor, Element, ConcreteElements, ObjectStructure.

Decision workflow

1. Describe the concrete design problem without naming a pattern.
2. Identify what varies and what must remain stable.
3. Establish the client-facing contract.
4. Assign each responsibility to a participant.
5. Prefer composition over inheritance unless inheritance is intrinsic to the pattern.
6. Preserve domain invariants and dependency direction.
7. Implement the smallest viable version.
8. Add tests proving substitutability, collaboration, and failure behavior.
9. Compare the result with a simpler alternative.
10. Record why this pattern is justified.

Kotlin implementation guidance

• Prefer immutable values and constructor injection.