Visitor Pattern
Visitor: start from the problem
See the responsibilities
A small expression tree needs evaluation and node counting. Adding every new operation directly to every node can tie unrelated analyses to the data representation.
This is a behavioral pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Visitor addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Visitor places an operation in a separate object with methods for the supported element types. Elements accept a visitor and dispatch to their appropriate method. The operation can then traverse the structure under a defined rule.
Our NumberNode accepts evaluation or counting visitors. Adding operations is convenient when the element types are stable. Adding a new element type can require changing every visitor’s contract.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
class NumberNode {
constructor(value) { this.value = value; }
accept(visitor) { return visitor.number(this); }
}
const evaluate = {number: node => node.value};
const count = {number: node => 1};
const node = new NumberNode(9);
console.log(node.accept(evaluate));
console.log(node.accept(count));Expected output
9
1Choose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it for a relatively stable node family with several operations, such as a syntax tree needing validation, printing and analysis.
Visitors can expose representation details and couple every operation to all element types. Adding frequently changing node types becomes expensive. Specify traversal ownership to avoid duplicated or skipped children.
Distinguish the neighbouring patterns
Iterator supplies traversal. Visitor supplies operations for element types. Composite can provide the tree structure they operate on; these patterns can collaborate.
Follow sequential traversal, tree structures, evaluating a defined expression language to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Visitor, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside evaluating a defined expression language.
Reaching the recap and completing the quizzes are separate milestones.