Visitor Design Pattern in Java: Complete Guide with Real-World E-Commerce Example
Imagine you are developing an e-commerce application. An order can contain physical products, digital products, and shipping charges.
Initially, your application only needs to calculate the order total. Later, the business team asks you to generate invoices. After that, they need tax reports, product summaries, and export reports.
One common approach is to keep adding new methods to every product class. As the application grows, these classes become responsible for too many operations.
The Visitor Design Pattern in Java solves this problem. Instead of placing every new operation inside your existing classes, you can create separate visitor classes. Each visitor performs a particular operation on the objects it visits.
In this guide, we will understand the pattern from the basics and implement it using a practical e-commerce order example with complete, runnable Java 8 code, original diagrams, double dispatch explained, a Spring Boot use case, and interview questions.
1. What Is the Visitor Design Pattern?
The Visitor pattern is a behavioral design pattern that lets you add new operations to a group of existing object types without modifying those classes every time a new operation is required.
In simple words, Visitor separates the operations from the objects on which those operations are performed.
For example, consider these classes in an e-commerce application:
PhysicalProductDigitalProductShippingCharge
Now imagine that you need three different operations:
- Generate an invoice.
- Calculate tax.
- Generate an order summary.
Without Visitor, you may add these operations to every product class. With Visitor, each operation can be implemented in a separate visitor class.
In simple words: Visitor lets you add operations to an object structure without changing the element classes.
Key participants
- Element: Defines an
accept()method that accepts a visitor. - Concrete Element: Represents the actual objects the visitor can visit.
- Visitor: Declares an operation for each concrete element type.
- Concrete Visitor: Implements the operations for different element types.
- Object Structure: Holds or provides access to the elements being visited.
- Client: Creates visitors and passes them to the object structure.
2. Real-World Example: E-Commerce Order Processing
Suppose a customer places an order containing a laptop (physical product), an online Java course (digital product), and a shipping charge (delivery service).
All these objects belong to an order, but they have different characteristics. A physical product has a quantity and may require delivery. A digital product is delivered electronically. A shipping charge represents a service fee.
Now the business wants to perform different operations on these objects.
| Object | Invoice | Tax Report | Order Summary |
|---|---|---|---|
| Physical Product | Product price × quantity | Calculate applicable tax | Show product details |
| Digital Product | Product price × quantity | Calculate applicable tax | Show digital item details |
| Shipping Charge | Shipping amount | Calculate applicable tax | Show delivery charge |
Notice something important: the objects remain the same, but the operations are different. That is exactly the problem the Visitor Design Pattern helps solve.
3. How the Visitor Pattern Works
The Visitor pattern generally consists of the following components:
- Element: Defines an
accept()method that accepts a visitor. - Concrete Element: Represents actual objects that the visitor can visit.
- Visitor: Declares an operation for each concrete element type.
- Concrete Visitor: Implements the operations for different element types.
- Object Structure: Holds or provides access to the elements being visited.
The important point is that the elements do not implement the
operation themselves. They delegate to the appropriate
visit() method on the visitor that has been passed in.
What changes after introducing a visitor?
The element classes stop accumulating operation-specific methods. New operations become new visitor classes, and the element classes stay focused on their data and accept behavior.
4. Visitor Pattern Class Diagram
This original diagram shows how the e-commerce classes interact with the Visitor pattern.
accept(), visitors declare
visit() per element type, and concrete visitors
implement each operation.
Each concrete element implements the accept() method.
When a visitor is passed to an element, the element calls the matching
visit() method.
5. Understanding Double Dispatch
One of the most important concepts behind the Visitor Design Pattern is double dispatch.
In normal method overriding, Java selects the overridden method based primarily on the runtime type of the object receiving the method call.
Visitor uses two object types to select the operation:
- The actual element type, such as
PhysicalProductorDigitalProduct. - The visitor type, such as
InvoiceVisitororTaxReportVisitor.
Consider this code:
OrderItem item = new PhysicalProduct("Laptop", 50000, 1);
OrderVisitor visitor = new InvoiceVisitor();
item.accept(visitor);
The actual object is PhysicalProduct. Its
accept() method calls:
visitor.visit(this);
Because this refers to a PhysicalProduct,
Java selects:
visit(PhysicalProduct product)That is how Visitor achieves double dispatch using Java's method overloading and runtime method dispatch.
6. Complete Running Java Example
Let's build the complete example. We will create an e-commerce order containing physical products, digital products, and shipping charges.
We will then perform three operations using three different visitors:
InvoiceVisitor— generates the invoice.TaxReportVisitor— calculates an illustrative tax report.OrderSummaryVisitor— generates an order summary.
Project structure
For simplicity, all classes are placed in a single Java file. This makes the example easy to copy and run.
VisitorPatternDemo.javaComplete Java code
import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
// 1. Element interface
interface OrderItem {
void accept(OrderVisitor visitor);
}
// 2. Visitor interface
interface OrderVisitor {
void visit(PhysicalProduct product);
void visit(DigitalProduct product);
void visit(ShippingCharge shippingCharge);
}
// 3. Concrete element: Physical product
class PhysicalProduct implements OrderItem {
private final String name;
private final BigDecimal price;
private final int quantity;
public PhysicalProduct(String name, BigDecimal price, int quantity) {
this.name = name;
this.price = price;
this.quantity = quantity;
}
public String getName() {
return name;
}
public BigDecimal getPrice() {
return price;
}
public int getQuantity() {
return quantity;
}
public BigDecimal getTotal() {
return price.multiply(BigDecimal.valueOf(quantity));
}
@Override
public void accept(OrderVisitor visitor) {
visitor.visit(this);
}
}
// 4. Concrete element: Digital product
class DigitalProduct implements OrderItem {
private final String name;
private final BigDecimal price;
private final int quantity;
public DigitalProduct(String name, BigDecimal price, int quantity) {
this.name = name;
this.price = price;
this.quantity = quantity;
}
public String getName() {
return name;
}
public BigDecimal getPrice() {
return price;
}
public int getQuantity() {
return quantity;
}
public BigDecimal getTotal() {
return price.multiply(BigDecimal.valueOf(quantity));
}
@Override
public void accept(OrderVisitor visitor) {
visitor.visit(this);
}
}
// 5. Concrete element: Shipping charge
class ShippingCharge implements OrderItem {
private final String description;
private final BigDecimal amount;
public ShippingCharge(String description, BigDecimal amount) {
this.description = description;
this.amount = amount;
}
public String getDescription() {
return description;
}
public BigDecimal getAmount() {
return amount;
}
@Override
public void accept(OrderVisitor visitor) {
visitor.visit(this);
}
}
// 6. Object structure
class Order {
private final List<OrderItem> items;
public Order(List<OrderItem> items) {
this.items = new ArrayList<OrderItem>(items);
}
public void accept(OrderVisitor visitor) {
for (OrderItem item : items) {
item.accept(visitor);
}
}
}
// 7. Concrete visitor: Invoice generation
class InvoiceVisitor implements OrderVisitor {
private BigDecimal total = BigDecimal.ZERO;
@Override
public void visit(PhysicalProduct product) {
BigDecimal amount = product.getTotal();
total = total.add(amount);
System.out.println(
"Physical Product: " + product.getName()
+ " | Amount: " + amount
);
}
@Override
public void visit(DigitalProduct product) {
BigDecimal amount = product.getTotal();
total = total.add(amount);
System.out.println(
"Digital Product: " + product.getName()
+ " | Amount: " + amount
);
}
@Override
public void visit(ShippingCharge shippingCharge) {
BigDecimal amount = shippingCharge.getAmount();
total = total.add(amount);
System.out.println(
"Shipping: " + shippingCharge.getDescription()
+ " | Amount: " + amount
);
}
public BigDecimal getTotal() {
return total;
}
}
// 8. Concrete visitor: Tax calculation
class TaxReportVisitor implements OrderVisitor {
private BigDecimal totalTax = BigDecimal.ZERO;
// Demonstration rates only.
// Actual tax rates depend on applicable laws and product classification.
private static final BigDecimal PRODUCT_TAX_RATE =
new BigDecimal("0.18");
private static final BigDecimal SHIPPING_TAX_RATE =
new BigDecimal("0.05");
@Override
public void visit(PhysicalProduct product) {
calculateTax(
product.getName(),
product.getTotal(),
PRODUCT_TAX_RATE
);
}
@Override
public void visit(DigitalProduct product) {
calculateTax(
product.getName(),
product.getTotal(),
PRODUCT_TAX_RATE
);
}
@Override
public void visit(ShippingCharge shippingCharge) {
calculateTax(
shippingCharge.getDescription(),
shippingCharge.getAmount(),
SHIPPING_TAX_RATE
);
}
private void calculateTax(
String itemName,
BigDecimal amount,
BigDecimal taxRate
) {
BigDecimal tax = amount.multiply(taxRate);
totalTax = totalTax.add(tax);
System.out.println(
itemName + " | Tax: " + tax
);
}
public BigDecimal getTotalTax() {
return totalTax;
}
}
// 9. Concrete visitor: Order summary
class OrderSummaryVisitor implements OrderVisitor {
private int physicalProductCount;
private int digitalProductCount;
private int shippingChargeCount;
@Override
public void visit(PhysicalProduct product) {
physicalProductCount++;
System.out.println(
"Physical: " + product.getName()
+ " | Quantity: " + product.getQuantity()
);
}
@Override
public void visit(DigitalProduct product) {
digitalProductCount++;
System.out.println(
"Digital: " + product.getName()
+ " | Quantity: " + product.getQuantity()
);
}
@Override
public void visit(ShippingCharge shippingCharge) {
shippingChargeCount++;
System.out.println(
"Service: " + shippingCharge.getDescription()
);
}
public void printCounts() {
System.out.println(
"Physical product entries: " + physicalProductCount
);
System.out.println(
"Digital product entries: " + digitalProductCount
);
System.out.println(
"Shipping entries: " + shippingChargeCount
);
}
}
// 10. Main class
public class VisitorPatternDemo {
public static void main(String[] args) {
// Create order items
PhysicalProduct laptop = new PhysicalProduct(
"Laptop",
new BigDecimal("50000.00"),
1
);
DigitalProduct javaCourse = new DigitalProduct(
"Java Course",
new BigDecimal("2000.00"),
1
);
ShippingCharge shipping = new ShippingCharge(
"Standard Delivery",
new BigDecimal("500.00")
);
// Create order
Order order = new Order(
Arrays.<OrderItem>asList(
laptop,
javaCourse,
shipping
)
);
// Operation 1: Generate invoice
System.out.println("===== INVOICE =====");
InvoiceVisitor invoiceVisitor = new InvoiceVisitor();
order.accept(invoiceVisitor);
System.out.println(
"Invoice Total: " + invoiceVisitor.getTotal()
);
// Operation 2: Calculate tax
System.out.println();
System.out.println("===== TAX REPORT =====");
TaxReportVisitor taxVisitor = new TaxReportVisitor();
order.accept(taxVisitor);
System.out.println(
"Total Tax: " + taxVisitor.getTotalTax()
);
// Operation 3: Generate order summary
System.out.println();
System.out.println("===== ORDER SUMMARY =====");
OrderSummaryVisitor summaryVisitor =
new OrderSummaryVisitor();
order.accept(summaryVisitor);
summaryVisitor.printCounts();
}
}How to run the program
Step 1: Install JDK 8 or above.
Step 2: Create a file named VisitorPatternDemo.java.
Step 3: Copy the complete code into the file.
Step 4: Open a terminal in the file's directory and compile it:
javac VisitorPatternDemo.javaStep 5: Run the program:
java VisitorPatternDemo7. Expected Output
===== INVOICE =====
Physical Product: Laptop | Amount: 50000.00
Digital Product: Java Course | Amount: 2000.00
Shipping: Standard Delivery | Amount: 500.00
Invoice Total: 52500.00
===== TAX REPORT =====
Laptop | Tax: 9000.0000
Java Course | Tax: 360.0000
Standard Delivery | Tax: 25.0000
Total Tax: 9385.0000
===== ORDER SUMMARY =====
Physical: Laptop | Quantity: 1
Digital: Java Course | Quantity: 1
Service: Standard Delivery
Physical product entries: 1
Digital product entries: 1
Shipping entries: 1Note: The tax percentages in this program are illustrative examples to demonstrate the Visitor pattern. They are not a statement of actual GST rates or tax treatment. A production billing system must use the applicable tax rules and classifications.
How the responsibilities are separated
| Component | Responsibility |
|---|---|
OrderItem |
Element interface exposing accept(visitor). |
PhysicalProduct / DigitalProduct / ShippingCharge |
Concrete elements that hold data and dispatch to the correct visitor method. |
OrderVisitor |
Declares one visit() method per element type. |
InvoiceVisitor / TaxReportVisitor / OrderSummaryVisitor |
Concrete visitors that implement specific operations. |
Order |
Object structure that iterates its items and passes the visitor along. |
VisitorPatternDemo |
Client that builds the order and runs each visitor. |
8. Understanding the Code Step by Step
Step 1: OrderItem interface
interface OrderItem {
void accept(OrderVisitor visitor);
}
This is the Element interface. Every item in the order implements this
interface. The accept() method allows a visitor to
perform an operation on the current object.
Step 2: OrderVisitor interface
interface OrderVisitor {
void visit(PhysicalProduct product);
void visit(DigitalProduct product);
void visit(ShippingCharge shippingCharge);
}
This interface defines one visit() method for each
supported element type. When you introduce a new visitor, it must
implement the operations for all these element types.
Step 3: Concrete elements
PhysicalProduct, DigitalProduct, and
ShippingCharge implement OrderItem. Each
class implements accept() by calling
visitor.visit(this).
This is an important part of the pattern because the actual element
type determines which overloaded visit() method is
selected.
Step 4: Concrete visitors
InvoiceVisitor, TaxReportVisitor, and
OrderSummaryVisitor each implement a different business
operation. Notice that we did not add invoice, tax, or summary methods
to the product classes. We added new visitor classes instead.
Step 5: Order object structure
public void accept(OrderVisitor visitor) {
for (OrderItem item : items) {
item.accept(visitor);
}
}
The Order class maintains the collection of items. It
passes the same visitor to each item, allowing the visitor to process
the entire order.
9. Execution Flow Diagram
This diagram shows what happens when the invoice visitor processes an order.
visit() method on the
visitor.
The execution sequence is:
- The application creates an
InvoiceVisitor. - The visitor is passed to the
Order. - The
Orderiterates through its items. - Each item calls
accept(visitor). - The correct
visit()method executes for that item type. - The visitor builds the invoice.
10. Why Not Just Use If-Else or instanceof?
You may wonder why we need a design pattern for this. Can't we simply
use instanceof?
Yes, we can write code like this:
for (OrderItem item : items) {
if (item instanceof PhysicalProduct) {
// Calculate physical product amount
} else if (item instanceof DigitalProduct) {
// Calculate digital product amount
} else if (item instanceof ShippingCharge) {
// Calculate shipping amount
}
}This approach works for small applications. However, as the number of operations grows, similar type-checking logic may be repeated in multiple places.
For example, invoice generation, tax calculation, reporting, and
exporting may all contain their own instanceof checks.
Visitor gives these operations a consistent structure and keeps them
separate from the element classes.
11. When Should You Use the Visitor Pattern?
Visitor is useful when the object structure is relatively stable but you frequently need to add new operations to it.
1. E-commerce applications
Generate invoices, tax reports, product summaries, and exports for different order item types.
2. Compiler development
Compilers often use visitors to traverse abstract syntax trees and perform operations such as type checking, code generation, and validation.
3. Reporting systems
Different visitors can generate PDF reports, CSV exports, statistics, and summaries from the same object structure.
4. File system operations
A visitor can perform operations on files and directories, such as calculating sizes, validating files, or generating reports.
5. Document processing
Different visitors can export the same document structure to HTML, XML, or another format.
12. Visitor Pattern in Spring Boot
Visitor is not limited to standalone Java applications. It can also be useful in Spring Boot projects when a stable domain model needs several independent operations.
For example, imagine an order service that needs to generate different reports for an order. A simplified Spring Boot architecture could look like this:
Controller
|
v
OrderService
|
v
Order
|
+---- PhysicalProduct
|
+---- DigitalProduct
|
+---- ShippingCharge
|
v
OrderVisitor
|
+---- InvoiceVisitor
|
+---- TaxReportVisitor
|
+---- OrderSummaryVisitorYou could expose separate endpoints for different operations:
GET /api/orders/101/invoice
GET /api/orders/101/tax-report
GET /api/orders/101/summaryThe controller would call an application service. The service would load the order, select the appropriate visitor, and execute it.
Example: a focused Spring Boot service
import org.springframework.stereotype.Service;
import java.math.BigDecimal;
@Service
public class OrderReportService {
public BigDecimal calculateTax(Order order) {
TaxReportVisitor visitor = new TaxReportVisitor();
order.accept(visitor);
return visitor.getTotalTax();
}
}This is a simplified integration example. In a real Spring Boot application, you would also need to consider dependency injection, DTO mapping, transaction boundaries, validation, authorization, and how visitors are registered or selected.
Is this always the best design?
No. Avoid forcing Visitor into every service. If your object model changes frequently or the operations are simple, ordinary service classes or polymorphism may be easier to maintain.
13. Advantages and Disadvantages of the Visitor Pattern
Advantages
- Easy to add new operations: Add another visitor without adding operation methods to every existing element class.
- Separation of concerns: Business operations stay separate from the domain objects.
- Centralized operations: All behavior for a particular operation is grouped in one visitor.
- Supports double dispatch: The operation can depend on both the visitor type and the concrete element type.
- Useful for complex object structures: A visitor can process many related element types consistently.
Disadvantages
-
Adding a new element is difficult: Every visitor
must be updated with a new
visit()method. - More classes: Each new operation may require another visitor implementation.
- Encapsulation concerns: Visitors may need access to element data, which can encourage exposing getters or internal details.
- Can become complex: For a small object model, Visitor may introduce unnecessary complexity.
- Not ideal for frequently changing object structures: Adding new element types affects the visitor interface and its implementations.
The best Visitor setup is stable in its element types but still expanding in operations. If the element structure changes frequently, the pattern will slow you down.
14. Visitor vs Strategy Pattern
Both Visitor and Strategy are behavioral design patterns, but they solve different problems.
| Feature | Visitor | Strategy |
|---|---|---|
| Main purpose | Add operations to an object structure | Choose between interchangeable algorithms |
| Focus | Different element types | Different ways to perform a task |
| Typical methods | visit() and accept() |
execute() or calculate() |
| Adding a new operation | Usually add a new visitor | Usually add a new strategy implementation |
| Adding a new element type | Requires updating visitors | Usually does not require updating strategies |
| Example | Generate invoices for different order items | Choose UPI, card, or wallet payment processing |
Strategy changes how an operation is performed. Visitor adds different operations across a group of element types.
15. Visitor Pattern and SOLID Principles
Single Responsibility Principle (SRP)
Each visitor can have one focused responsibility.
InvoiceVisitor generates invoices, while
TaxReportVisitor calculates tax.
Open/Closed Principle (OCP)
You can add new operations by creating new visitors without modifying the existing element classes. However, adding a new element type still requires changes to the visitor interface and its implementations. Visitor does not make every kind of extension closed to modification.
Dependency Inversion Principle (DIP)
Concrete elements depend on the OrderVisitor abstraction
rather than directly depending on InvoiceVisitor or
TaxReportVisitor.
Practical takeaway
Visitor promotes clear separation between data and behavior, but it does not make a design fully SOLID on its own. Apply it where its trade-offs match your project's stability profile.
16. Best Practices
- Use Visitor when your element types are stable and new operations are expected.
- Keep each visitor focused on one business operation. Avoid mixing unrelated responsibilities.
-
Use meaningful visitor and element names.
The
visit()overloads should be obvious from the class names. - Avoid exposing unnecessary internal fields just to support visitors. Expose only what the operation truly needs.
- Use immutable domain objects where appropriate. This makes double dispatch and visitors easier to reason about.
- Keep business rules, especially financial and tax rules, in well-tested components.
- Do not use Visitor simply because it is a recognized design pattern. Favor clarity and simplicity.
-
Write unit tests for every visitor and every supported
element type.
This ensures each
visit()method behaves correctly.
17. Java Interview Questions and Answers
Q1. What is the Visitor Design Pattern?
Visitor is a behavioral design pattern that allows new operations to be added to an existing object structure without modifying the element classes for every new operation.
Q2. Why is Visitor called a behavioral design pattern?
Because it focuses on how operations are performed on a group of objects and how responsibilities are distributed between visitors and elements.
Q3. What are the main components of Visitor?
The main components are Element, Concrete Element, Visitor, Concrete Visitor, and Object Structure.
Q4. What is double dispatch?
Double dispatch is a technique in which the operation selected depends
on both the runtime type of the element and the visitor. In Java,
Visitor commonly achieves this using method overriding and overloaded
visit() methods.
Q5. Why do we use the accept() method?
The accept() method allows an element to receive a visitor
and call the appropriate visit() method using its own
concrete type.
Q6. What is the difference between Visitor and Strategy?
Visitor adds operations to a stable object structure. Strategy provides interchangeable algorithms for performing a particular task.
Q7. What is the biggest disadvantage of Visitor?
Adding a new element type is difficult because the visitor interface and all concrete visitors generally need to be updated.
Q8. Can Visitor violate encapsulation?
Yes. If visitors need access to internal fields, developers may expose getters or other access methods. The design should expose only the information required by the operations.
Q9. Is Visitor useful when new element types are added frequently?
Usually not. Visitor works best when the element structure is stable and new operations are added more frequently than new element types.
Q10. Can we have multiple visitors for the same object?
Yes. For example, the same Order can be processed by
InvoiceVisitor, TaxReportVisitor, and
OrderSummaryVisitor.
Q11. Does Visitor require inheritance?
It requires a common element abstraction or another way to expose the
accept() operation. Concrete elements commonly implement
a shared interface.
Q12. Can Visitor work with collections?
Yes. An object structure can contain a collection of elements and pass the same visitor to each element, as demonstrated in the e-commerce example.
Q13. How does Visitor support the Open/Closed Principle?
It allows new operations to be added through new visitor implementations without changing existing element classes. However, new element types still require visitor updates.
Q14. Can Visitor be used in Spring Boot?
Yes. It can be used in service-layer workflows for reporting, exporting, validation, and processing different domain object types. It should be used only when its structure provides a real benefit.
Q15. What is the difference between Visitor and Iterator?
Iterator provides a way to traverse a collection. Visitor defines
operations to perform on different element types. They can work
together, as the Order example demonstrates.
Q16. Why does every concrete visitor implement every visit() method?
The visitor interface defines the supported element types. A concrete visitor must implement the operation for each of those types, even if some operations do nothing for a particular type.
Q17. Can a visitor return a value?
Yes. The visit() methods can return values instead of
void. For example, a visitor can return a calculated
amount, a validation result, or a generated report.
Q18. Is Visitor suitable for payment reversal in a payment gateway?
Visitor is not a payment reversal mechanism. It can perform different operations on payment-related domain objects, but reversing an actual payment requires a separate business workflow involving provider APIs, transaction state, idempotency, and reconciliation.
Q19. What happens when a new product type is introduced?
You add a new element class and a corresponding visit()
method to the visitor interface. All concrete visitors must then
implement that new method.
Q20. When should you avoid the Visitor Design Pattern?
Avoid it when the object structure changes frequently, when there are only a few simple operations, or when ordinary polymorphism and service classes are easier to understand and maintain.
18. Frequently Asked Questions
Is Visitor a creational, structural, or behavioral pattern?
Visitor is a behavioral design pattern.
Can Visitor be implemented in Java 8?
Yes. The implementation in this article uses standard Java features available in Java 8 and does not require external libraries.
Does Visitor follow the Open/Closed Principle?
It supports adding new operations without changing existing element classes. However, adding new element types requires updating the visitor interface and concrete visitors.
Is Visitor used in real-world software?
Yes. It is useful in compiler implementations, document processing, reporting systems, and applications that perform multiple operations on a stable object structure.
Can Visitor replace all instanceof checks?
No. Visitor is a design choice for a particular object structure. It is
not a universal replacement for instanceof or ordinary
polymorphism.
Is the Visitor pattern part of the Gang of Four patterns?
Yes. Visitor is one of the behavioral patterns in the Gang of Four design-pattern catalog.
19. Quick Revision Checklist
- Visitor is a behavioral design pattern.
- It adds new operations without modifying existing element classes.
- Elements expose
accept(); visitors declarevisit(). - Visitor uses double dispatch to select the correct
visit()method. - Adding a new operation means adding a new visitor, not editing elements.
- Adding a new element type means updating the visitor interface and all visitors.
- Visitor is best when element types are stable and operations grow.
- It can expose element internals, so control what visitors can access.
- Spring Boot services can use Visitor for reporting and export workflows.
- Avoid Visitor when the object structure changes frequently or operations are simple.
Conclusion
The Visitor Design Pattern is useful when you have a stable group of
object types but need to perform different operations on them. In our
e-commerce example, PhysicalProduct,
DigitalProduct, and ShippingCharge remained
unchanged while we introduced invoice generation, tax calculation, and
order summary operations through separate visitors.
The most important thing to remember is this: when your object structure stays stable but new operations keep coming, Visitor can help keep your code organized.
But don't use it everywhere. If your object types change frequently, the Visitor pattern can make maintenance harder rather than easier. Understand the problem first, then choose the design pattern that makes your code simpler.
If you are preparing for Java interviews, practise implementing Visitor alongside Strategy, Command, and Template Method. Understanding when each pattern is useful matters more than memorizing its definition.