The strategy patternConcept

Explanation

The strategy pattern lets a specific behavior — a payment method, a sort comparator, a retry policy — be swapped independently of the code that uses it, chosen by the caller rather than hard-coded into the consumer. Classic object-oriented form needs an abstract Strategy interface, one concrete class per algorithm, and a context class holding a reference to whichever concrete strategy was injected. Rust rarely needs that much ceremony, because it has three lighter-weight ways to express "pluggable behavior," and which one applies depends entirely on when the strategy is chosen:

a plain function or closure parameter, bound by Fn/FnMut/FnOnce, when the strategy really is just one operation and the caller already has the right closure in scope; a generic function or type bounded by a trait, when exactly one strategy is picked per call site and known at compile time, so the compiler monomorphizes it away entirely and pays no dispatch cost at all; or a &dyn Trait/Box<dyn Trait> trait object, when the concrete strategy genuinely isn't known until runtime — read from configuration, chosen by a user, or selected from a registry.

Reach for a real, multi-method Strategy trait — rather than a bare closure — once a strategy needs more than one operation or its own constructor and state: a closure covers "run this one function," but a strategy exposing both pay and refund, say, needs a trait with two methods. The choice between a generic bound and dyn Trait for that trait is exactly the static vs. dynamic dispatch tradeoff: pay a small vtable indirection to pick the strategy at runtime, or fix it at compile time for zero overhead but one strategy per instantiation.

Strategy and command are close cousins and easy to conflate: a strategy is a swappable algorithm invoked repeatedly as part of some larger operation (how to price an order), a command is a swappable action usually invoked once and often queued or undone (send this specific order). Both lean on the same &dyn Trait/Box<dyn Trait> mechanism underneath.

Basic usage example

trait PaymentStrategy {
    fn pay(&self, amount_cents: u64) -> String;
}

struct CreditCard;
impl PaymentStrategy for CreditCard {
    fn pay(&self, amount_cents: u64) -> String {
        format!("Charged {amount_cents} cents to credit card")
    }
}

struct PayPal;
impl PaymentStrategy for PayPal {
    fn pay(&self, amount_cents: u64) -> String {
        format!("Charged {amount_cents} cents via PayPal")
    }
}

fn checkout(strategy: &dyn PaymentStrategy, amount_cents: u64) { // <- behavior is chosen by the caller, not hard-coded here
    println!("{}", strategy.pay(amount_cents));
}

checkout(&CreditCard, 1999);
checkout(&PayPal, 2499);

Best practices & deeper information

trait PaymentStrategy {
    fn pay(&self, amount_cents: u64) -> String;
}

struct CreditCard;
impl PaymentStrategy for CreditCard {
    fn pay(&self, amount_cents: u64) -> String { format!("card: {amount_cents}") }
}

struct PayPal;
impl PaymentStrategy for PayPal {
    fn pay(&self, amount_cents: u64) -> String { format!("paypal: {amount_cents}") }
}

fn select_strategy(method: &str) -> Box<dyn PaymentStrategy> { // <- concrete type decided at runtime, from request data
    match method {
        "paypal" => Box::new(PayPal),
        _ => Box::new(CreditCard),
    }
}

let strategy = select_strategy("paypal");
println!("{}", strategy.pay(500));

trait DiscountStrategy {
    fn discount(&self, price_cents: u32) -> u32;
}

struct NoDiscount;
impl DiscountStrategy for NoDiscount {
    fn discount(&self, price_cents: u32) -> u32 { price_cents }
}

struct PercentOff(u32);
impl DiscountStrategy for PercentOff {
    fn discount(&self, price_cents: u32) -> u32 {
        price_cents - (price_cents * self.0 / 100)
    }
}

fn final_price<S: DiscountStrategy>(price_cents: u32, strategy: &S) -> u32 { // <- monomorphized per strategy type: no vtable, no allocation
    strategy.discount(price_cents)
}

println!("{}", final_price(2000, &PercentOff(10)));