Replacing Switch Statements With the Strategy Pattern in C#

Switch statements feel comfortable at first. A handful of cases, a clear default, and the code reads fine on a Friday arvo when you're keen to ship before the long weekend. But the same construct tends to sprawl as the business grows. New payment providers, new shipping carriers, new discount tiers — each one nudges another case into a method that used to be tidy. In dev teams from Perth to Brisbane, this is a familiar refactor that ends up on the backlog more often than anyone would like to admit.

The Strategy Pattern offers a cleaner way forward. It lets you encapsulate each branch of behaviour behind a shared interface, then pick the right algorithm at runtime. For C# developers heading to the C# Corner Annual Conference 2020, the pattern fits neatly alongside discussions of SOLID principles, dependency injection, and the other refactoring tools that come up across the three-day agenda.

Why Switch Statements Creep Out of Control

A switch statement is fine when it represents a closed set of values the compiler can verify. The trouble begins when the set is actually open. A PaymentProcessor method that handles "CreditCard", "PayPal", and "BankTransfer" today will be asked to handle "Afterpay", "Klarna", and "ZipPay" tomorrow. Every new branch forces a change in code that should ideally be left alone.

This is the textbook violation of the Open/Closed Principle. The class is open for change, but only because someone has gone in with a screwdriver. Unit tests start duplicating each branch, code review gets noisy, and the merge conflicts pile up faster than a Melbourne tram in peak hour. Worse, the conditional logic often hides domain rules that deserve a proper home of their own rather than a corner of a switch block.

There is also a readability tax. A long switch buried in the middle of a service method is harder to step through than a polymorphic call. Tools like ReSharper and the latest Roslyn analyzers will flag switch blocks that exceed a certain size, but the real cost is cognitive. New starters at ANZ's tech hub in Melbourne or at Atlassian's Sydney offices spend their first week mapping these tangles before they can ship anything useful, and that ramp-up time shows up directly in sprint velocity.

What the Strategy Pattern Actually Solves

The Strategy Pattern is one of the original behavioural patterns from the Gang of Four. Its purpose is to define a family of algorithms, encapsulate each one, and make them interchangeable. In C#, that usually means an interface that declares the contract, concrete classes that implement it, and a context that holds a reference to whichever implementation is currently active. The pattern sits comfortably with delegates and Func<T> pipelines for simpler cases, and graduates to full interface hierarchies when the behaviour carries its own state.

What it really solves is the coupling between selection and execution. A switch statement does both in the same place: it selects a branch and runs the logic. The Strategy Pattern separates those concerns. Selection can live in a factory, a DI container, or a runtime lookup keyed on configuration. Execution lives in a small focused class with one job and a name that tells you exactly what it does.

This separation pays off in three concrete ways. First, you can add a new strategy without touching the existing ones, so the Open/Closed Principle is finally respected. Second, each strategy becomes trivial to test in isolation, which plays well with xUnit, NUnit, and the modern testing culture at Australian meetups like DDD Melbourne or the .NET user groups in Sydney and Adelaide. Third, the strategies themselves become reusable across other contexts — the same IExchangeRateProvider that powers the checkout flow can drive a back-office reconciliation job without duplication.

Comparing Switch Statements and the Strategy Pattern

The table is a useful starting point, but the real difference shows up the day someone asks for a new payment method on the morning standup. With a switch, the team knows it means another merge conflict and another branch of untested logic. With the strategy approach, someone can drop in a new file and register it, then grab a flat white while the build runs.

Implementing the Pattern in a Real C# Scenario

Imagine an order discount service that applies a different calculation depending on the customer tier: Bronze, Silver, Gold, and a new "Founders" tier that the marketing team in Sydney keeps inventing. The switch-based version packs all four formulas into one method, with magic numbers sprinkled around like Vegemite on toast and a default branch that quietly swallows unknown cases.

The strategy-based version starts with an interface that captures the contract:

public interface IDiscountStrategy
{
    decimal Calculate(Order order);
}

Each tier gets its own class. A GoldDiscountStrategy might apply a percentage, a FoundersDiscountStrategy might combine a percentage with a fixed bonus, and a BronzeDiscountStrategy might be a simple flat rate. None of them know about each other, and each one can be reasoned about in isolation.

Selection happens in a factory that takes the customer tier and returns the right strategy, or even simpler, in the DI container registration where you map Enum → IDiscountStrategy. ASP.NET Core's built-in container, or libraries like Autofac and Lamar, handle this elegantly. A practical walk-through of using isolated environments for .NET work, similar to setting up Azure DevTest Labs for each strategy experiment, makes the local testing loop far smoother and keeps the build matrix clean.

The context class — often called the DiscountService — simply holds the chosen strategy and delegates the calculation. There is no switch, no if-else ladder, and no default branch that quietly swallows the unknown case. Unknown tiers can throw or fall back to a NoDiscountStrategy, and that fallback is itself a class you can test, swap, and version like any other piece of code.

When Strategy Makes Sense and When to Walk Away

The Strategy Pattern is not a free upgrade. It introduces more files, more types, and a slightly steeper onboarding curve for developers who have not worked with it before. For a switch that handles three values out of an enum the compiler can verify, the extra ceremony is overkill. The rule of thumb is to reach for Strategy when the cases represent behaviour, not data, and when that behaviour is likely to grow over time.

It also makes sense when the branch logic is genuinely complex. A simple switch (statusCode) that maps to an HTTP status description does not need an interface hierarchy. But a switch that triggers different workflows, side effects, or business rules absolutely does. If you find yourself passing the same context object into each branch, that is a strong smell that the branches want to be classes with their own dependencies and configuration.

Finally, keep an eye on performance. A switch on an integer compiles to a jump table that is faster than any interface dispatch in tight loops. For high-throughput code paths — order matching engines, hot telemetry pipelines, the kind of work done by teams at IC Markets in Sydney — the overhead of virtual dispatch is worth measuring with BenchmarkDotNet. For ordinary business logic, the cost is invisible and the maintainability gain is worth far more than a few nanoseconds.

Bringing this back to the C# Corner Annual Conference 2020, this is the kind of refactor worth tucking into your toolkit before you board the flight home. Sessions on design patterns, dependency injection, and modern C# language features all reinforce the same idea: write code that bends rather than breaks when the next requirement lands in your lap. The Strategy Pattern is one of the cleanest ways to keep that promise, and once you start using it, you will spot the places where a switch has been quietly doing the work of an entire class.