Visitor pattern in LLD - System Design Guide

Problem Statement

When you add new operations to a complex object structure, modifying each class to add these operations leads to code duplication and violates the open/closed principle. This makes the system hard to maintain and extend without risking bugs.

Solution

The Visitor pattern separates operations from the object structure by letting you define new operations in separate visitor classes. Each visitor implements the operation for each object type, and objects accept visitors to perform the operation without changing their own code.

Architecture

Object A

┌─────────┐

↓

Visitor

┌───────────────┐ ┌─────────────┐

This diagram shows objects A and B each having an accept method that takes a visitor. The visitor has specific visit methods for each object type, separating operations from object structures.

Trade-offs

✓ Pros

→

Allows adding new operations without modifying existing object classes.

→

Keeps related operations together in visitor classes, improving code organization.

→

Supports complex object structures with multiple element types.

→

Promotes adherence to the open/closed principle.

✗ Cons

→

Adding new object types requires modifying all visitor classes, reducing flexibility.

→

Can increase complexity by introducing additional visitor classes and interfaces.

→

May lead to tight coupling between visitor and element classes.

Use when you have a stable set of object classes but need to add many new unrelated operations frequently, especially in complex object structures.

Avoid when the object structure changes often by adding new element types, as this requires updating all visitor implementations.

Real World Examples

Eclipse IDE

Uses Visitor pattern to separate operations like syntax checking, formatting, and refactoring on abstract syntax trees without modifying the tree node classes.

ANTLR (parser generator)

Applies Visitor pattern to traverse parse trees and perform different actions like interpretation or code generation without changing the tree node classes.

Code Example

Before applying Visitor, adding a new operation requires modifying each element class, violating open/closed principle. After applying Visitor, new operations are added as new visitor classes without changing element classes, improving extensibility and separation of concerns.

LLD

### Before (without Visitor pattern):

class ElementA:
    def operation1(self):
        print("ElementA operation1")

    def operation2(self):
        print("ElementA operation2")

class ElementB:
    def operation1(self):
        print("ElementB operation1")

    def operation2(self):
        print("ElementB operation2")

# Adding new operation requires modifying ElementA and ElementB

### After (with Visitor pattern):

class ElementA:
    def accept(self, visitor):
        visitor.visit_element_a(self)

class ElementB:
    def accept(self, visitor):
        visitor.visit_element_b(self)

class Visitor:
    def visit_element_a(self, element):
        pass

    def visit_element_b(self, element):
        pass

class Operation1Visitor(Visitor):
    def visit_element_a(self, element):
        print("ElementA operation1")

    def visit_element_b(self, element):
        print("ElementB operation1")

class Operation2Visitor(Visitor):
    def visit_element_a(self, element):
        print("ElementA operation2")

    def visit_element_b(self, element):
        print("ElementB operation2")

# Usage

elements = [ElementA(), ElementB()]

op1 = Operation1Visitor()
for e in elements:
    e.accept(op1)

op2 = Operation2Visitor()
for e in elements:
    e.accept(op2)

Alternatives

Strategy pattern

Encapsulates interchangeable algorithms inside classes and uses composition, focusing on varying behavior rather than operations on object structures.

Use when: Choose when you want to change the algorithm or behavior of a single object dynamically rather than adding operations across many object types.

Command pattern

Encapsulates a request as an object to parameterize clients with queues or logs, focusing on actions rather than operations on object structures.

Use when: Choose when you need to queue, log, or undo operations rather than separate operations from object structures.

Summary

Visitor pattern separates operations from object structures to add new behaviors without modifying existing classes.

It improves code organization and adheres to the open/closed principle by defining operations in visitor classes.

It is best used when object types are stable but operations change frequently.