Strategy Pattern

A strategy is an algorithm behind an interface, chosen while the program is running. The caller knows it needs a discount calculated; it does not know which of the four ways is about to be used.

The pain it answers is specific. A calculation that branches on a type or a category value has to be edited every time a new case appears, and the same set of cases usually gets copied into two or three other methods that also need to know. The pattern turns "edit the method" into "add a class", and turns a value scattered across several switches into one thing the container resolves.

public decimal DiscountFor(CustomerCategory category, OrderTotals totals)
{
    switch (category)
    {
        case CustomerCategory.Standard:
            return 0m;

        case CustomerCategory.Trade:
            return totals.Net * 0.05m;

        case CustomerCategory.Wholesale:
            return totals.Net >= 5_000m
                ? totals.Net * 0.12m
                : totals.Net * 0.08m;

        case CustomerCategory.Staff:
            return Math.Min(totals.Net * 0.25m, 200m);

        default:
            throw new NotSupportedException($"No discount rule for {category}.");
    }
}

• Four unrelated commercial rules share one method. A change to the staff cap is a change to the file that also decides wholesale pricing, so the review has to cover both and the merge conflicts land here.
• The rules do not change together. Trade terms come from sales, the staff discount from HR, the wholesale threshold from finance. Three reasons to change, one location — the problem the first lesson of this course named.
• This switch is rarely alone. The same four categories usually appear again in the method that writes invoice wording and again in the one that sets payment terms. Add a fifth category and the compiler tells you nothing; you find the other two switches when a customer complains.
• The default case is doing real work. Throwing on an unrecognised value is better than returning zero, because a silently missing discount reaches a customer rather than a developer.

public interface IDiscountRule
{
    CustomerCategory AppliesTo { get; }
    decimal DiscountFor(OrderTotals totals);
}

internal sealed class WholesaleDiscount : IDiscountRule
{
    public CustomerCategory AppliesTo => CustomerCategory.Wholesale;

    public decimal DiscountFor(OrderTotals totals) =>
        totals.Net >= 5_000m ? totals.Net * 0.12m : totals.Net * 0.08m;
}

public sealed class DiscountCalculator
{
    private readonly Dictionary<CustomerCategory, IDiscountRule> _rules;

    public DiscountCalculator(IEnumerable<IDiscountRule> rules) =>
        _rules = rules.ToDictionary(rule => rule.AppliesTo);

    public decimal For(CustomerCategory category, OrderTotals totals) =>
        _rules.TryGetValue(category, out IDiscountRule? rule)
            ? rule.DiscountFor(totals)
            : throw new NotSupportedException($"No discount rule registered for {category}.");
}

// Program.cs — one line per rule, and this is where the cost shows
builder.Services.AddScoped<IDiscountRule, StandardDiscount>();
builder.Services.AddScoped<IDiscountRule, TradeDiscount>();
builder.Services.AddScoped<IDiscountRule, WholesaleDiscount>();
builder.Services.AddScoped<IDiscountRule, StaffDiscount>();

• Each rule declares the category it handles, so the mapping lives with the rule rather than in a separate lookup somebody has to remember to update.
• Injecting IEnumerable of an interface gives you every registered implementation. The container builds the list; the calculator turns it into a dictionary once, at construction.
• Testing the wholesale threshold is now a constructor call and two assertions. No other rule is loaded, so a mistake in one cannot make another test fail.
• The throw survives the refactor. Removing the switch removed the branching, not the need to decide what happens when a value has no rule — and that decision is worth keeping explicit.
• Four registration lines are the honest price. Forget one and the failure appears at run time for one category of customer, not at compile time. Some teams prefer assembly scanning to avoid that; scanning trades an explicit list for magic, which is a real choice rather than an obvious improvement.