Strategy Pattern for Dummies

Everything crammed into one place. Adding a payment method or a discount rule means re-opening this method and risking the existing branches. This is what you're about to refactor away.

// ❌ BAD — every new rule = an edit to this same method
public void ProcessPayment(Order order, string method)
{
    decimal total = order.Price * order.Quantity;

    // discount rules
    if (order.CustomerType == "vip")      total -= total * 0.20m;
    else if (order.CustomerType == "reg") total -= total * 0.10m;
    if (total > 1000m)                    total -= 50m;
    // tomorrow: black friday? edit here.
    // next week: loyalty points?  edit here.

    // payment rules
    if (method == "card")
        Console.WriteLine($"Card payment of {total:C}");
    else if (method == "cash")
        Console.WriteLine($"Cash payment of {total:C}");
    // tomorrow: paypal? crypto? applepay? edit here too.
    else
        throw new ArgumentException("Unknown method");
}

By the end of this page you'll have the same console app — but split into tiny, swappable classes. Adding PayPal will be a 15-line file that you drop in. No existing class will change.

// ── The shape of the refactored solution ───────────
Interface/
  IPaymentStrategy.cs       ← contract for "how to pay"
  IDiscountStrategy.cs      ← contract for "how to discount"

Strategies/
  CardPaymentStrategy.cs    ← one way to pay
  CashPaymentStrategy.cs    ← another way to pay
  RegularDiscountStrategy.cs
  VipDiscountStrategy.cs
  BigOrderDiscountStrategy.cs
  BlackFridayDiscount.cs    ← drop-in, nobody else changes
  CompositeDiscountStrategy.cs  ← chains discounts

Factory/
  PaymentStrategyFactory.cs ← picks a payment strategy
  DiscountStrategyFactory.cs ← builds a composite discount

Service/
  PaymentService.cs         ← orchestrates, knows no concretes

Program.cs                  ← reads input, hands off

// Promise: every new payment method or discount rule
//          will be a NEW file, never an edit. That's Strategy.

Anything that knows how to charge a customer implements this interface. The service will only ever see this type — never the concrete class.

namespace ConsoleApp34.Interface;

public interface IPaymentStrategy
{
    // Given a final total, perform the payment.
    // No return value — payment either succeeds or throws.
    void Process(decimal total);
}

// That's the whole contract. Resist the urge to add
// Validate(), GetFee(), GetReceipt() "while you're here".
// Each addition forces EVERY implementer to provide it.

A discount takes the current total and returns a new one. By returning a decimal (instead of mutating something), discounts compose — the output of one feeds the input of the next. (You'll see why that matters in Section 6.)

namespace ConsoleApp34.Interface;

public interface IDiscountStrategy
{
    // Pure function: take the running total,
    // return the new total after applying this discount.
    decimal Apply(decimal currentTotal);
}

// Two interfaces, one method each.
// Total of 4 lines of code that will save you 400.

"How to pay by card." Real life would call a gateway here; for the console app we just print. The interface doesn't care.

using ConsoleApp34.Interface;

namespace ConsoleApp34.Strategies;

public class CardPaymentStrategy : IPaymentStrategy
{
    public void Process(decimal total)
    {
        Console.WriteLine($"Processing card payment of {total:C}");
    }
}

"How to pay by cash." Same shape, different body. The two classes don't know each other exist — and they don't need to.

using ConsoleApp34.Interface;

namespace ConsoleApp34.Strategies;

public class CashPaymentStrategy : IPaymentStrategy
{
    public void Process(decimal total)
    {
        Console.WriteLine($"Processing cash payment of {total:C}");
    }
}

Four little classes. Each one implements Apply(decimal) and minds its own business. BlackFridayDiscount isn't even wired up yet — that's deliberate. It proves the point: a strategy can exist before any caller uses it, ready to plug in.

public class RegularDiscountStrategy : IDiscountStrategy
{
    public decimal Apply(decimal currentTotal)
        => currentTotal - currentTotal * 0.1m;       // -10%
}

public class VipDiscountStrategy : IDiscountStrategy
{
    public decimal Apply(decimal currentTotal)
    {
        Console.WriteLine("VIP applied");
        return currentTotal - currentTotal * 0.2m;   // -20%
    }
}

public class BigOrderDiscountStrategy : IDiscountStrategy
{
    public decimal Apply(decimal currentTotal)
    {
        if (currentTotal > 1000m) return currentTotal - 50m;
        return currentTotal;                          // -€50 over €1000
    }
}

public class BlackFridayDiscount : IDiscountStrategy
{
    public decimal Apply(decimal currentTotal)
    {
        Console.WriteLine("Black Friday discount applied");
        return currentTotal - currentTotal * 0.3m;   // -30% (drop-in)
    }
}

A dictionary keyed by an enum beats a switch for two reasons: (1) it's data, not control flow — you can extend it without changing logic; (2) the strategies are instantiated once and reused (cheap, thread-safe when stateless).

using ConsoleApp34.Interface;
using ConsoleApp34.Strategies;

namespace ConsoleApp34;

public class PaymentStrategyFactory
{
    // One instance per strategy — built once, reused forever.
    private readonly Dictionary<PaymentMethod, IPaymentStrategy> _strategies = new()
    {
        [PaymentMethod.Card] = new CardPaymentStrategy(),
        [PaymentMethod.Cash] = new CashPaymentStrategy(),
        // [PaymentMethod.PayPal] = new PayPalPaymentStrategy(),  ← drop-in
    };

    public IPaymentStrategy Create(PaymentMethod method) => _strategies[method];
}

// PaymentMethod is just a tiny enum that bounds valid input:
public enum PaymentMethod { Card, Cash }

Discounts stack, so the factory doesn't return one strategy — it builds a list and wraps it in a Composite (Section 6). The service still gets back a single IDiscountStrategy and doesn't know any of this happened.

using ConsoleApp34.Interface;
using ConsoleApp34.Strategies;

namespace ConsoleApp34;

public class DiscountStrategyFactory
{
    public IDiscountStrategy Create(Order order)
    {
        var strategies = new List<IDiscountStrategy>();

        // VIPs get the VIP discount; everyone else gets the regular one.
        if (order.CustomerType == "vip")
            strategies.Add(new VipDiscountStrategy());
        else
            strategies.Add(new RegularDiscountStrategy());

        // Big orders always get an extra €50 off, on top of the above.
        strategies.Add(new BigOrderDiscountStrategy());

        // Wrap the whole list as a single IDiscountStrategy.
        return new CompositeDiscountStrategy(strategies);
    }
}

Read this and count the conditionals. There are none. The factories pick; the composite chains; the strategy charges. The service just connects them.

namespace ConsoleApp34.Service;

public class PaymentService(
    DiscountStrategyFactory discountFactory,
    PaymentStrategyFactory  paymentFactory)
{
    private readonly DiscountStrategyFactory _discountFactory = discountFactory;
    private readonly PaymentStrategyFactory  _paymentFactory  = paymentFactory;

    public void ProcessPayment(Order order, PaymentMethod paymentMethod)
    {
        var discount = _discountFactory.Create(order);          // ← which discounts?
        var payment  = _paymentFactory.Create(paymentMethod);   // ← which payment?

        decimal subtotal = order.GetSubtotal();
        decimal total    = discount.Apply(subtotal);            // ← apply (maybe chained)
        payment.Process(total);                                 // ← charge
    }
}

// Six lines of body. Compare with the 20-line `if/else` from Section 1.
// Now extend the system: count how many lines you have to ADD to support
// PayPal. (Answer: ~10 in a new file, plus one dictionary line in the factory.)

The composition root: read the user's input, build the order, construct the factories, hand them to the service, and run. In an ASP.NET Core app, this whole block is replaced by a DI container — the philosophy is identical.

using ConsoleApp34;
using ConsoleApp34.Service;

var order = new Order
{
    CustomerType = GetCustomerType().Trim().ToLower(),
    Price        = GetPrice(),
    Quantity     = GetQuantity()
};

if (!TryGetPaymentMethod(out var paymentMethod))
{
    Console.WriteLine("Invalid payment method.");
    return;
}

// ── The composition root ─────────────────────────────
var paymentService = new PaymentService(
    new DiscountStrategyFactory(),
    new PaymentStrategyFactory());

paymentService.ProcessPayment(order, paymentMethod);
Console.WriteLine("Order complete!");

// Helper methods omitted for brevity — they just Console.ReadLine.

Strategy + Factory + Composite is one of the most common "trio" combinations in real codebases. Memorise the shape — you'll recognise it everywhere from ASP.NET Core middleware to ETL pipelines.

// User input  ──>  PaymentService
//                  │
//                  ├──> DiscountStrategyFactory.Create(order)
//                  │       └──> CompositeDiscountStrategy(
//                  │              [ VipDiscountStrategy,
//                  │                BigOrderDiscountStrategy ])
//                  │
//                  ├──> PaymentStrategyFactory.Create(method)
//                  │       └──> CardPaymentStrategy
//                  │
//                  ├──> total = discount.Apply(subtotal)
//                  └──> payment.Process(total)
//
// Add PayPal?      → +1 new file in /Strategies + 1 line in factory.
// Add Black Friday → +1 dictionary entry to enable it. ALREADY written.
// Add a logger?    → wrap each strategy in a LoggingDecorator (next pattern!).

A pocket guide. Pin it next to your monitor for the next time you catch yourself writing a third else if.

// ── Symptoms (use Strategy) ─────────────────────
//  • A switch on a "type" / "kind" / "mode" string or enum.
//  • Several methods doing "the same thing, different way".
//  • Every new variant requires editing an existing method.
//  • You can describe the choice as a noun: "a discount", "a sort", "an exporter".

// ── Recipe ──────────────────────────────────────
//  1. Define a tiny interface (1 method if possible).
//  2. Move each branch's code into its own class implementing the interface.
//  3. Add a factory (dictionary, switch, or DI registration) to pick one.
//  4. The caller depends ONLY on the interface.
//  5. If multiple need to combine → wrap them in a Composite.

// ── Anti-symptoms (don't bother) ────────────────
//  • Exactly 2 branches that will never grow.
//  • The branches share > 80% of their code.
//  • The pick happens at compile time, not runtime.

// ── Cousins worth knowing ───────────────────────
//  Decorator — wraps a strategy to add behaviour (logging, caching).
//  State     — same shape, but the OBJECT swaps its own strategy.
//  Template Method — inherited fixed skeleton, only steps differ.
//                    (Strategy is its composition-based alternative.)