Comparison
Interpreter patternvsVisitor pattern
Interpreter pattern
each node in the parsed expression knows how to evaluate itself, and evaluating the root walks the whole tree.
Representing a small language's grammar as a class per rule, each able to evaluate itself against a context. It is the least-used pattern in the catalogue — anything beyond a tiny grammar wants a real parser and a visitor over the AST — but the shape appears whenever a codebase grows a rules engine, a search filter syntax or a permission expression. Say plainly in an interview that you would recognise it and would not reach for it.
Full entry →Visitor pattern
you added a new operation over the whole tree by writing one class, and did not touch any of the node types.
Moving an operation out of a structure's element classes into a separate object, which each element calls back with its own type. It trades one kind of extensibility for another: adding an operation becomes easy and adding a node type becomes a change to every visitor — the expression problem, stated concretely. It is genuinely used in compilers, linters and anything that walks an AST, and almost nowhere else.
Full entry →