Both the visitor pattern and the strategy pattern are behavioral design patterns from the Gang of Four catalog, and they share a common thread -- both externalize algorithms away from the objects that use them. But the similarities end quickly once you dig into the mechanics. When you compare the visitor vs strategy pattern in C# side by side, you'll find that they solve fundamentally different problems around extensibility, dispatch mechanisms, and how operations interact with object structures. Understanding these differences is essential for choosing the right tool in your C# applications.
In this article, we'll break down each pattern's core purpose, walk through side-by-side C# code examples that solve a discount calculation problem with each approach, and explore the practical criteria you should use when deciding between the visitor vs strategy pattern. We'll also cover extensibility trade-offs, examine whether these patterns can be combined, and finish with a detailed FAQ section.
Quick Overview: Visitor and Strategy Foundations
Before diving into the visitor vs strategy comparison, let's establish what each pattern does individually.
The Visitor Pattern
The visitor pattern lets you define new operations on an object structure without modifying the classes of the elements you're operating on. It achieves this through a technique called double dispatch -- each element in the structure "accepts" a visitor, and then calls back into the visitor with a reference to itself. This two-step dispatch allows the visitor to execute the correct operation based on both the visitor type and the concrete element type.
Think of it like a building inspector visiting different rooms in a building. The inspector (visitor) has specialized knowledge for each type of room -- they check wiring in electrical rooms, plumbing in bathrooms, and fire exits in hallways. The building structure stays fixed, but you can send different inspectors through without remodeling anything.
The Strategy Pattern
The strategy pattern encapsulates a single algorithm behind an interface and lets clients swap that algorithm at runtime without changing the consuming code. A context object holds a reference to a strategy, delegates work to it, and doesn't care which concrete implementation is behind the interface. Strategies are typically stateless -- they receive input, process it, and return output.
Think of it like choosing a shipping method for a package. The package and destination stay the same, but you swap the delivery algorithm -- overnight, ground, express -- depending on the situation. Each algorithm is interchangeable and self-contained.
Side-by-Side Visitor vs Strategy Comparison
Here's a direct comparison of the visitor vs strategy pattern across the dimensions that matter most when choosing between them.
Intent and Purpose
The strategy pattern's intent is to encapsulate one interchangeable algorithm for a single context. It answers the question: "How should this one thing be done?" You have a context that needs a behavior, and you swap that behavior at runtime.
The visitor pattern's intent is to define multiple operations that can be applied across a fixed set of element types. It answers the question: "What operations should I perform on each type of element in this structure?" You have a collection of different object types, and you want to run varied operations across all of them without touching their code.
This intent difference is the most important aspect of the visitor vs strategy comparison. A strategy handles one algorithm for one context. A visitor handles many operations across many element types.
Dispatch Mechanism
The strategy pattern uses simple single dispatch. The context calls a method on whatever strategy interface it holds. The runtime resolves the call based on the concrete strategy type -- straightforward polymorphism.
The visitor pattern uses double dispatch. An element calls Accept(visitor), and inside that method, it calls visitor.Visit(this). The first dispatch resolves the element type; the second resolves the visitor type. This two-step mechanism is what allows the visitor to execute type-specific logic without casting or type checks.
Extensibility Direction
This is where the visitor vs strategy pattern comparison gets interesting. The two patterns have opposite extensibility trade-offs.
The strategy pattern makes it easy to add new algorithms. You implement a new class that satisfies the strategy interface and inject it into the context. No existing code changes. But the "shape" of the operation is fixed -- the strategy interface defines a single method signature that all algorithms must follow.
The visitor pattern makes it easy to add new operations. You implement a new visitor class with a Visit method for each element type, and the entire object structure gains a new capability without any element classes changing. But adding new element types is expensive -- every existing visitor must be updated with a new Visit overload.
Statefulness
Strategies are typically stateless. They receive their input through method parameters, process it, and return a result. A strategy doesn't retain information between invocations.
Visitors can accumulate state as they traverse a structure. A visitor might sum up totals, collect errors, or build a result object as it visits each element. This stateful traversal is one of the visitor pattern's strengths -- it can gather information across many elements in a single pass.
C# Code Examples: Discount Calculation
Let's make the visitor vs strategy pattern comparison concrete. We'll implement a discount calculation system -- first with the strategy pattern, then with the visitor pattern -- to show how the same domain looks under each approach.
Strategy Pattern Approach
With the strategy pattern, we define a discount algorithm interface and swap implementations at runtime. This works well when we have a single product type and want to vary the discount logic:
public interface IDiscountStrategy
{
decimal CalculateDiscount(decimal price, int quantity);
}
public sealed class PercentageDiscount : IDiscountStrategy
{
private readonly decimal _percentage;
public PercentageDiscount(decimal percentage)
{
_percentage = percentage;
}
public decimal CalculateDiscount(
decimal price,
int quantity)
{
return price * quantity * (_percentage / 100m);
}
}
public sealed class BulkDiscount : IDiscountStrategy
{
public decimal CalculateDiscount(
decimal price,
int quantity)
{
if (quantity >= 100)
return price * quantity * 0.20m;
if (quantity >= 50)
return price * quantity * 0.10m;
return 0m;
}
}
public sealed class NoDiscount : IDiscountStrategy
{
public decimal CalculateDiscount(
decimal price,
int quantity)
{
return 0m;
}
}
The context class accepts any discount strategy through dependency injection:
public sealed class OrderProcessor
{
private IDiscountStrategy _discountStrategy;
public OrderProcessor(IDiscountStrategy discountStrategy)
{
_discountStrategy = discountStrategy;
}
public void SetDiscountStrategy(
IDiscountStrategy discountStrategy)
{
_discountStrategy = discountStrategy;
}
public decimal CalculateTotal(
decimal price,
int quantity)
{
decimal subtotal = price * quantity;
decimal discount = _discountStrategy
.CalculateDiscount(price, quantity);
return subtotal - discount;
}
}
Usage is simple. You pick a strategy, process the order, and get the result:
var processor = new OrderProcessor(
new PercentageDiscount(15));
decimal total = processor.CalculateTotal(10.00m, 5);
// total: 42.50 (50 - 7.50 discount)
processor.SetDiscountStrategy(new BulkDiscount());
total = processor.CalculateTotal(10.00m, 100);
// total: 800 (1000 - 200 discount)
The strategy pattern shines here because we're varying a single algorithm for a single context. Adding a new discount type is as easy as implementing IDiscountStrategy -- no other classes need to change. This simplicity is a hallmark of the strategy approach in the visitor vs strategy comparison.
Visitor Pattern Approach
Now let's tackle a scenario where the visitor pattern is more appropriate. Suppose our order system has multiple product types -- physical goods, digital downloads, and subscription services -- each with different discount rules. We want to add operations across all of these types without modifying them:
public interface IOrderItemVisitor
{
void Visit(PhysicalProduct product);
void Visit(DigitalProduct product);
void Visit(Subscription subscription);
}
public interface IOrderItem
{
decimal Price { get; }
void Accept(IOrderItemVisitor visitor);
}
public sealed class PhysicalProduct : IOrderItem
{
public decimal Price { get; }
public decimal Weight { get; }
public PhysicalProduct(decimal price, decimal weight)
{
Price = price;
Weight = weight;
}
public void Accept(IOrderItemVisitor visitor)
{
visitor.Visit(this);
}
}
public sealed class DigitalProduct : IOrderItem
{
public decimal Price { get; }
public string LicenseType { get; }
public DigitalProduct(
decimal price,
string licenseType)
{
Price = price;
LicenseType = licenseType;
}
public void Accept(IOrderItemVisitor visitor)
{
visitor.Visit(this);
}
}
public sealed class Subscription : IOrderItem
{
public decimal Price { get; }
public int MonthsRemaining { get; }
public Subscription(
decimal price,
int monthsRemaining)
{
Price = price;
MonthsRemaining = monthsRemaining;
}
public void Accept(IOrderItemVisitor visitor)
{
visitor.Visit(this);
}
}
Now we create a visitor that calculates discounts differently for each product type. The visitor accumulates state as it traverses the order:
public sealed class DiscountVisitor : IOrderItemVisitor
{
public decimal TotalDiscount { get; private set; }
public void Visit(PhysicalProduct product)
{
// Heavy items get a shipping discount
if (product.Weight > 10m)
TotalDiscount += product.Price * 0.05m;
}
public void Visit(DigitalProduct product)
{
// Enterprise licenses get a volume discount
if (product.LicenseType == "Enterprise")
TotalDiscount += product.Price * 0.15m;
}
public void Visit(Subscription subscription)
{
// Long-term subscribers get loyalty discounts
if (subscription.MonthsRemaining > 12)
TotalDiscount += subscription.Price * 0.10m;
}
}
Usage shows the visitor traversing a heterogeneous collection:
List<IOrderItem> orderItems = new()
{
new PhysicalProduct(100m, 15m),
new DigitalProduct(200m, "Enterprise"),
new Subscription(50m, 24),
};
var discountVisitor = new DiscountVisitor();
foreach (var item in orderItems)
{
item.Accept(discountVisitor);
}
// TotalDiscount: 5 + 30 + 5 = 40
decimal totalDiscount = discountVisitor.TotalDiscount;
The power of the visitor pattern becomes clear when you need a second operation. Adding a tax calculation visitor requires zero changes to the element classes:
public sealed class TaxVisitor : IOrderItemVisitor
{
public decimal TotalTax { get; private set; }
public void Visit(PhysicalProduct product)
{
TotalTax += product.Price * 0.08m;
}
public void Visit(DigitalProduct product)
{
// Digital goods are tax-exempt in this example
TotalTax += 0m;
}
public void Visit(Subscription subscription)
{
TotalTax += subscription.Price * 0.05m;
}
}
This is the visitor vs strategy pattern distinction in action. The visitor adds new operations without changing elements. The strategy adds new algorithms without changing the context. They pull extensibility in opposite directions.
Can You Combine Visitor and Strategy Patterns?
Yes, and there are practical scenarios where combining the visitor vs strategy pattern makes sense. The key insight is that these patterns operate at different levels of abstraction.
Consider a scenario where a visitor traverses an object structure but needs to vary its internal algorithm for each element type. You could inject strategies into a visitor to control how specific calculations work:
public sealed class ConfigurableDiscountVisitor
: IOrderItemVisitor
{
private readonly IDiscountStrategy _physicalStrategy;
private readonly IDiscountStrategy _digitalStrategy;
public decimal TotalDiscount { get; private set; }
public ConfigurableDiscountVisitor(
IDiscountStrategy physicalStrategy,
IDiscountStrategy digitalStrategy)
{
_physicalStrategy = physicalStrategy;
_digitalStrategy = digitalStrategy;
}
public void Visit(PhysicalProduct product)
{
TotalDiscount += _physicalStrategy
.CalculateDiscount(product.Price, 1);
}
public void Visit(DigitalProduct product)
{
TotalDiscount += _digitalStrategy
.CalculateDiscount(product.Price, 1);
}
public void Visit(Subscription subscription)
{
// Fixed logic for subscriptions
if (subscription.MonthsRemaining > 12)
TotalDiscount += subscription.Price * 0.10m;
}
}
In this combination, the visitor handles the structural traversal and type-specific dispatch while the strategy pattern handles the interchangeable algorithm within specific visit methods. The visitor decides "what to operate on" and the strategy decides "how to calculate it." This layered approach works well with inversion of control containers where both the visitors and the strategies can be resolved through dependency injection.
Extensibility Trade-Offs: New Operations vs New Algorithms
One of the most critical aspects of the visitor vs strategy pattern comparison is understanding what each pattern makes easy to extend and what it makes hard.
Strategy: Easy to Add Algorithms, Fixed Operation Shape
The strategy pattern excels when you need to add new ways of performing a single operation. Imagine you start with two discount strategies and then need a third, a fourth, and a fifth over time. Each new strategy is just a new class that implements the interface. The context class, the consuming code, and all existing strategies remain untouched. This makes the strategy pattern a natural fit for scenarios driven by dependency injection where you register new implementations and the container resolves them at runtime.
However, the strategy interface is fixed. If you need to change the shape of the operation -- say adding a parameter or supporting a new return type -- every strategy implementation must be updated. The strategy pattern optimizes for variation within a fixed contract.
Visitor: Easy to Add Operations, Fixed Element Set
The visitor pattern excels when you need to add new operations across a fixed set of types. If your object structure rarely changes but you constantly need new ways to process it, the visitor is ideal. Each new operation is a new visitor class that implements a Visit method per element type.
But adding a new element type is painful. Every existing visitor needs a new Visit overload, which can mean touching dozens of classes if your system has many visitors. This is sometimes called the "expression problem" -- the difficulty of extending both the data types and the operations in a type-safe way.
This trade-off is the heart of the visitor vs strategy pattern decision. Ask yourself: will I more often add new algorithms for a single operation, or new operations across a set of types?
When to Choose Each Pattern
Here's a practical decision guide for the visitor vs strategy pattern in C#:
Choose the strategy pattern when you have a single context that needs to vary one behavior. The behavior has a stable interface, but the implementations change. Think discount algorithms, sorting strategies, validation rules, or command execution strategies. The strategy pattern is simpler, requires less boilerplate, and integrates cleanly with dependency injection.
Choose the visitor pattern when you have a heterogeneous collection of types that need multiple unrelated operations applied to them. The set of element types is stable, but you expect to add new operations over time. Think document processing, composite tree traversals, compiler AST operations, or report generation across a hierarchy. The visitor pattern requires more upfront structure but pays off in extensibility for new operations.
Avoid the visitor pattern when your element hierarchy changes frequently. Every new element type forces updates to all existing visitors. If your types are evolving, the visitor becomes a maintenance burden.
Avoid the strategy pattern when you need type-specific behavior across multiple element types in a single pass. Strategies don't know about element types -- they work with a generic interface. If you find yourself adding type checks inside a strategy, that's a signal the visitor pattern might be a better fit.
Frequently Asked Questions
What is the core difference between the visitor and strategy pattern?
The core difference between the visitor vs strategy pattern in C# is scope. The strategy pattern encapsulates a single interchangeable algorithm for one context -- you swap how one thing is done. The visitor pattern defines multiple operations across a set of element types using double dispatch -- you add what can be done to an entire object structure without modifying its classes. Strategies vary one algorithm; visitors vary many operations.
When should I use the visitor pattern instead of the strategy pattern in C#?
Use the visitor pattern when you have a stable set of element types and need to add new operations over time without modifying those types. If you have a composite structure, an AST, or a hierarchy of domain objects that rarely changes, the visitor lets you define new processing logic as separate visitor classes. If instead you only need to swap one algorithm for a single object, the strategy pattern is simpler and more appropriate.
Can the visitor and strategy patterns be combined in C#?
Yes. A visitor can use strategies internally to vary the algorithm within specific Visit methods. The visitor handles structural traversal and type-specific dispatch, while the strategy handles the interchangeable calculation logic. This combination is useful when you need both type-aware operations and algorithm flexibility. It also works well with inversion of control for managing the injected strategies.
What is double dispatch and why does the visitor pattern need it?
Double dispatch is a technique where the method that gets called depends on both the runtime type of the object receiving the call and the runtime type of the argument. In C#, standard method calls use single dispatch -- only the receiver's type determines which method runs. The visitor pattern uses double dispatch through the Accept/Visit handshake: the element dispatches on its own type by calling visitor.Visit(this), and the visitor dispatches on the visitor type. This lets the visitor execute type-specific logic without casting or switch statements.
How does the strategy pattern handle multiple object types?
The strategy pattern isn't designed for type-specific behavior across multiple object types. It works with a single interface contract -- input goes in, output comes out. If you need to handle different types differently, you'd typically use the adapter pattern to normalize inputs or switch to the visitor pattern for type-aware operations. Forcing type-specific logic into a strategy leads to brittle if/switch chains that violate the open-closed principle.
What are the main drawbacks of the visitor pattern in C#?
The biggest drawback is the cost of adding new element types. Every new element requires a new Visit method in the visitor interface and implementations in all existing visitors. This can become a significant maintenance burden if your type hierarchy evolves frequently. The visitor pattern also introduces more boilerplate than the strategy pattern -- you need the visitor interface, the Accept method on every element, and the double dispatch wiring. For simple scenarios where a strategy suffices, reaching for the visitor is over-engineering.
How do the visitor and strategy patterns relate to other design patterns?
Both patterns complement other behavioral patterns. The visitor pattern pairs naturally with the composite pattern for traversing tree structures and with the interpreter pattern for evaluating expression trees. The strategy pattern integrates well with the command pattern when you need both algorithm flexibility and execution tracking, and with the mediator pattern for coordinating strategy selection across components. Both patterns benefit from dependency injection for managing their implementations.
Wrapping Up Visitor vs Strategy Pattern in C#
The visitor vs strategy pattern comparison comes down to what you want to extend and how your types interact. The strategy pattern is the simpler choice when you need interchangeable algorithms for a single context -- swap the behavior, keep the interface stable, and add new strategies freely. The visitor pattern is the right tool when you have a stable hierarchy of types and need to add new operations across all of them without touching their source code.
Both patterns externalize algorithms, which is why developers sometimes confuse them. The key differentiators are dispatch mechanism (visitor uses double dispatch, strategy uses single dispatch), extensibility direction (visitor adds operations, strategy adds algorithms), and scope (visitor operates across multiple types, strategy operates on one context).
Don't default to one pattern out of habit. Use the decision criteria we covered -- type stability, number of operations, dispatch needs, and algorithm variability -- to pick the right approach. And remember that combining both patterns is a valid and powerful technique when your system requires both type-aware traversal and algorithm flexibility.