Visitor pattern in LLD - System Design Exercise

Design: Visitor Pattern Implementation

Design the core Visitor pattern structure including element interfaces, visitor interfaces, concrete elements, and concrete visitors. Out of scope are specific domain operations or UI integration.

Functional Requirements

FR1: Allow adding new operations to existing object structures without modifying their classes

FR2: Support multiple types of elements in the object structure

FR3: Enable different visitor implementations to perform distinct operations on elements

FR4: Maintain separation of concerns between data structures and operations

Non-Functional Requirements

NFR1: The system should handle up to 1000 elements in the object structure efficiently

NFR2: Operations should execute with minimal overhead (target under 10ms per visit)

NFR3: Design should be extensible to add new visitors without changing element classes

NFR4: Maintain code clarity and simplicity for easy maintenance

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Element interface with accept(visitor) method

Concrete element classes implementing Element interface

Visitor interface with visit methods for each element type

Concrete visitor classes implementing Visitor interface

Object structure holding elements and managing traversal

Design Patterns

Visitor pattern for operation separation

Composite pattern if object structure is hierarchical

Double dispatch to resolve method calls

Open/Closed principle for extensibility

Reference Architecture

ObjectStructure
   |
   |-- Element (interface)
   |      |-- ConcreteElementA
   |      |-- ConcreteElementB
   |
   |-- Visitor (interface)
          |-- ConcreteVisitor1
          |-- ConcreteVisitor2

Components

Element Interface

Interface in chosen language

Defines accept(visitor) method for elements to accept visitors

Concrete Elements

Classes implementing Element interface

Represent different types of elements in the object structure

Visitor Interface

Interface with visit methods

Declares visit methods for each concrete element type

Concrete Visitors

Classes implementing Visitor interface

Implement specific operations to perform on elements

Object Structure

Collection or composite of elements

Holds elements and manages traversal for visitor application

Request Flow

1. Client creates object structure with multiple elements

2. Client creates a concrete visitor instance

3. Client calls accept(visitor) on each element in the structure

4. Each element calls visitor.visit(this) passing itself

5. Visitor executes operation specific to element type

6. Client collects or uses results from visitor operations

Database Schema

Not applicable for Visitor pattern as it is a behavioral design pattern focusing on object interactions rather than data storage.

Scaling Discussion

Bottlenecks

Large object structures causing slow traversal

Adding many element types increasing visitor interface complexity

Multiple visitors increasing processing time

Tight coupling if visitor interface changes frequently

Solutions

Use efficient data structures for object structure to speed traversal

Group similar element types or use default visit methods to reduce interface size

Apply visitors selectively or asynchronously to manage load

Design visitor interface carefully to minimize changes and use adapter patterns if needed

Interview Tips

Time: Spend 10 minutes explaining the problem and requirements, 15 minutes designing the interfaces and classes with diagrams, 10 minutes discussing scaling and trade-offs, and 10 minutes answering questions.

Explain the problem of adding operations without changing element classes

Describe how double dispatch works in Visitor pattern

Show clear separation between elements and operations

Discuss extensibility and maintenance benefits

Mention potential drawbacks like interface explosion and how to mitigate them

Practice

1. What is the main purpose of the Visitor pattern in system design?

easy

A. To separate operations from the objects on which they operate

B. To create multiple instances of a class

C. To restrict access to certain parts of an object

D. To simplify database queries

Solution

1. Step 1: Understand the Visitor pattern concept

   The Visitor pattern allows defining new operations on objects without changing their classes.

2. Step 2: Identify the main goal

   Its main goal is to separate the operation logic from the object structure to keep code flexible.

3. Final Answer:

   To separate operations from the objects on which they operate -> Option A

4. Quick Check:

   Visitor pattern = separates operations [OK]

Hint: Visitor pattern separates operations from objects [OK]

Common Mistakes:

• Confusing Visitor with Singleton pattern
• Thinking it creates object instances
• Assuming it controls access permissions

2. Which of the following is the correct method signature for a visitor interface method visiting an element called ElementA?

easy

A. void accept(ElementA element);

B. void acceptVisitor(ElementA visitor);

C. void visitElementA();

D. void visit(ElementA element);

Solution

1. Step 1: Recall Visitor interface method naming

   The visitor interface defines methods named visit with the element type as parameter.

2. Step 2: Match correct signature

   The correct signature is void visit(ElementA element); to visit ElementA.

3. Final Answer:

   void visit(ElementA element); -> Option D

4. Quick Check:

   Visitor method = visit(Element) [OK]

Hint: Visitor methods are named visit(Element) [OK]

Common Mistakes:

• Confusing accept and visit method names
• Using no parameters in visit method
• Swapping visitor and element in parameters

3. Given the following code snippet, what will be the output?

class ElementA {
  accept(visitor) {
    visitor.visit(this);
  }
}

class PrintVisitor {
  visit(element) {
    console.log('Visited element');
  }
}

const element = new ElementA();
const visitor = new PrintVisitor();
element.accept(visitor);

medium

A. Visited ElementA

B. Error: visit is not a function

C. Visited element

D. No output

Solution

1. Step 1: Trace accept method call

   The accept method calls visitor.visit(this), passing the element instance.

2. Step 2: Check visit method behavior

   The visit method logs 'Visited element' to the console.

3. Final Answer:

   Visited element -> Option C

4. Quick Check:

   Visitor.visit logs message [OK]

Hint: Visitor.visit prints message when accept calls it [OK]

Common Mistakes:

• Expecting element type name in output
• Thinking visit method is missing
• Assuming no output without explicit return

4. Identify the error in this Visitor pattern implementation:

class ElementB {
  accept(visitor) {
    visitor.accept(this);
  }
}

class ConcreteVisitor {
  visit(element) {
    console.log('Visiting element');
  }
}

medium

A. ElementB calls visitor.accept instead of visitor.visit

B. ConcreteVisitor should not have a visit method

C. accept method should return a value

D. ElementB should not have an accept method

Solution

1. Step 1: Check accept method call

   The accept method calls visitor.accept(this), but visitor has no accept method.

2. Step 2: Identify correct visitor method

   The visitor interface defines visit methods, so accept should call visitor.visit(this).

3. Final Answer:

   ElementB calls visitor.accept instead of visitor.visit -> Option A

4. Quick Check:

   accept calls visit, not accept [OK]

Hint: accept calls visitor.visit, not visitor.accept [OK]

Common Mistakes:

• Confusing method names accept and visit
• Expecting accept to return a value
• Removing accept method from element

5. You have a system with multiple element types and want to add a new operation without modifying existing element classes. How does the Visitor pattern help in this scenario?

hard

A. By using inheritance to extend element classes with new operations

B. By creating a new visitor class implementing the operation for all element types

C. By adding new methods to each element class directly

D. By storing operations inside element objects as data

Solution

1. Step 1: Understand the problem of adding new operations

   Modifying existing element classes is risky and breaks encapsulation.

2. Step 2: Apply Visitor pattern solution

   Create a new visitor class that implements the new operation for all element types, keeping element classes unchanged.

3. Final Answer:

   By creating a new visitor class implementing the operation for all element types -> Option B

4. Quick Check:

   Visitor adds operations via new visitor classes [OK]

Hint: Add new visitor class for new operations [OK]

Common Mistakes:

• Modifying element classes directly
• Using inheritance to add operations
• Embedding operations as data in elements