The Strategy Pattern in Rust

23 min read

In TypeScript you implement the strategy pattern with an interface and a family of classes: define interface DiscountStrategy, write a class per algorithm, and inject the chosen one into a context object. Rust supports that exact shape with trait objects, but it also gives you two other tools that a TypeScript developer usually reaches for last: generics (the strategy is fixed at compile time) and plain closures (the strategy is just a function value). This file is about choosing among those three, and why the closure version is often the most idiomatic answer in Rust.

Quick Overview

The strategy pattern lets you swap an algorithm at runtime without changing the code that uses it: a pricing engine that can apply different discount rules, a load balancer that can route requests by different policies, a serializer that can emit JSON or YAML. In TypeScript this is almost always “an interface plus a class per algorithm.” Rust offers three idiomatic encodings, and picking the right one is the whole skill:

Plain closures (impl Fn, Box<dyn Fn>) — the lightest option, ideal when the strategy is “just a function” with no extra state or methods.
Generics (<S: Strategy>) — the strategy is chosen at compile time, monomorphized to zero-cost static dispatch, like a TypeScript generic but with no type erasure.
Trait objects (Box<dyn Strategy>, &dyn Strategy) — the closest match to the OO version, chosen at runtime via a vtable, used when the set of strategies is open or selected from config.

Note: This page covers strategy specifically. The mechanics of dyn Trait and static-vs-dynamic dispatch are in Section 09: Trait Objects and Section 09: Trait Bounds. For building the concrete strategy values, see the sibling factory-pattern.md; for wiring strategies into a larger system, see dependency-injection.md.

TypeScript/JavaScript Example

A realistic checkout: the cart total is the same, but the discount applied depends on a promotion chosen at runtime. The textbook approach is an interface and a class per strategy, injected into a Checkout context.

1
// TypeScript - the classic OO strategy pattern
2
interface DiscountStrategy {
3
  apply(subtotal: number): number;
4
  name(): string;
5
}
6

7
class NoDiscount implements DiscountStrategy {
8
  apply(subtotal: number): number {
9
    return subtotal;
10
  }
11
  name(): string {
12
    return "none";
13
  }
14
}
15

16
class PercentOff implements DiscountStrategy {
17
  constructor(private fraction: number) {}
18
  apply(subtotal: number): number {
19
    return subtotal * (1 - this.fraction);
20
  }
21
  name(): string {
22
    return `${this.fraction * 100}% off`;
23
  }
24
}
25

26
class FlatOff implements DiscountStrategy {
27
  constructor(private amount: number) {}
28
  apply(subtotal: number): number {
29
    return Math.max(0, subtotal - this.amount);
30
  }
31
  name(): string {
32
    return `$${this.amount} off`;
33
  }
34
}
35

36
// The context holds whichever strategy was injected.
37
class Checkout {
38
  constructor(private discount: DiscountStrategy) {}
39
  total(subtotal: number): number {
40
    return Math.round(this.discount.apply(subtotal) * 100) / 100;
41
  }
42
}
43

44
const chosen = new PercentOff(0.1); // picked from config at runtime
45
const checkout = new Checkout(chosen);
46
console.log(checkout.total(100)); // 90

Output (Node v22):

1
90

Two things worth noticing for the comparison ahead. First, every DiscountStrategy is dispatched dynamically — this.discount.apply(...) is a runtime property lookup, the only dispatch JavaScript has. Second, TypeScript developers often write a whole class (PercentOff, FlatOff) where the “strategy” is really just one function. In JavaScript you could already pass a bare (subtotal: number) => number, and Rust leans hard into that instinct.

Rust Equivalent

Here is the same checkout three ways. Start with the most idiomatic Rust answer — a closure — then build up to generics and trait objects so you can see exactly what each buys you.

Version 1: plain closures (the idiomatic default)

When a strategy is “just a function,” make it a function. Any Fn(f64) -> f64 is a discount strategy; no trait, no struct, no class.

1
// Rust - the strategy is a closure. `impl Fn` means "any function-like value".
2
fn checkout(subtotal: f64, discount: impl Fn(f64) -> f64) -> f64 {
3
    let after = discount(subtotal);
4
    (after * 100.0).round() / 100.0
5
}
6

7
fn main() {
8
    let none = |s: f64| s;
9
    // A closure that *builds* a closure — strategies parameterized by data.
10
    let percent_off = |pct: f64| move |s: f64| s * (1.0 - pct);
11
    let flat_off = |amount: f64| move |s: f64| (s - amount).max(0.0);
12

13
    println!("none:    {:.2}", checkout(100.0, none));
14
    println!("10% off: {:.2}", checkout(100.0, percent_off(0.10)));
15
    println!("$15 off: {:.2}", checkout(100.0, flat_off(15.0)));
16

17
    // Choosing a strategy at runtime: box it, because each closure is a distinct type.
18
    let strategy: Box<dyn Fn(f64) -> f64> = if true {
19
        Box::new(percent_off(0.25))
20
    } else {
21
        Box::new(flat_off(15.0))
22
    };
23
    println!("boxed:   {:.2}", checkout(80.0, &strategy));
24
}

Real output:

1
none:    100.00
2
10% off: 90.00
3
$15 off: 85.00
4
boxed:   60.00

Version 2: generics (compile-time strategy, zero-cost)

When a strategy has more than one method or carries state worth naming, define a trait and make the context generic over it. The compiler generates a specialized copy per concrete strategy (monomorphization), so calls are inlined with no vtable.

1
// Rust - the strategy is a trait; the context is generic over it (static dispatch).
2
trait Validator {
3
    fn validate(&self, input: &str) -> Result<(), String>;
4
}
5

6
struct NonEmpty;
7
struct MaxLen(usize);
8

9
impl Validator for NonEmpty {
10
    fn validate(&self, input: &str) -> Result<(), String> {
11
        if input.is_empty() {
12
            Err("must not be empty".to_string())
13
        } else {
14
            Ok(())
15
        }
16
    }
17
}
18

19
impl Validator for MaxLen {
20
    fn validate(&self, input: &str) -> Result<(), String> {
21
        if input.len() > self.0 {
22
            Err(format!("max length is {}", self.0))
23
        } else {
24
            Ok(())
25
        }
26
    }
27
}
28

29
// `Field<V>` is monomorphized: one specialized type per V used.
30
struct Field<V: Validator> {
31
    name: String,
32
    validator: V,
33
}
34

35
impl<V: Validator> Field<V> {
36
    fn new(name: &str, validator: V) -> Self {
37
        Field { name: name.to_string(), validator }
38
    }
39
    fn check(&self, input: &str) -> Result<(), String> {
40
        self.validator
41
            .validate(input)
42
            .map_err(|e| format!("{}: {}", self.name, e))
43
    }
44
}
45

46
fn main() {
47
    let username = Field::new("username", NonEmpty);
48
    let bio = Field::new("bio", MaxLen(10));
49

50
    println!("{:?}", username.check(""));
51
    println!("{:?}", username.check("alice"));
52
    println!("{:?}", bio.check("this bio is way too long"));
53
    println!("{:?}", bio.check("short"));
54
}

Real output:

1
Err("username: must not be empty")
2
Ok(())
3
Err("bio: max length is 10")
4
Ok(())

Version 3: trait objects (runtime strategy, the OO shape)

When the strategy is selected at runtime — from a config file, a CLI flag, a database column — and you want to store different strategies in the same field or collection, use a trait object: Box<dyn Strategy>. This is the encoding that maps one-to-one onto the TypeScript class hierarchy.

1
// Rust - the strategy is a `Box<dyn Trait>` chosen at runtime (dynamic dispatch).
2
trait CompressionStrategy {
3
    fn compress(&self, data: &str) -> String;
4
    fn name(&self) -> &'static str;
5
}
6

7
struct NoCompression;
8
struct RunLength;
9

10
impl CompressionStrategy for NoCompression {
11
    fn compress(&self, data: &str) -> String {
12
        data.to_string()
13
    }
14
    fn name(&self) -> &'static str {
15
        "none"
16
    }
17
}
18

19
impl CompressionStrategy for RunLength {
20
    fn compress(&self, data: &str) -> String {
21
        let mut out = String::new();
22
        let mut chars = data.chars().peekable();
23
        while let Some(c) = chars.next() {
24
            let mut count = 1;
25
            while chars.peek() == Some(&c) {
26
                chars.next();
27
                count += 1;
28
            }
29
            out.push_str(&format!("{c}{count}"));
30
        }
31
        out
32
    }
33
    fn name(&self) -> &'static str {
34
        "rle"
35
    }
36
}
37

38
// The context stores the strategy behind `dyn`, so its concrete type can vary.
39
struct Archiver {
40
    strategy: Box<dyn CompressionStrategy>,
41
}
42

43
impl Archiver {
44
    fn new(strategy: Box<dyn CompressionStrategy>) -> Self {
45
        Archiver { strategy }
46
    }
47
    fn store(&self, data: &str) -> String {
48
        format!("[{}] {}", self.strategy.name(), self.strategy.compress(data))
49
    }
50
}
51

52
// A factory maps a runtime string to a concrete strategy (see factory-pattern.md).
53
fn make_strategy(name: &str) -> Box<dyn CompressionStrategy> {
54
    match name {
55
        "rle" => Box::new(RunLength),
56
        _ => Box::new(NoCompression),
57
    }
58
}
59

60
fn main() {
61
    let chosen = "rle"; // imagine this comes from config at runtime
62
    let archiver = Archiver::new(make_strategy(chosen));
63
    println!("{}", archiver.store("aaabbbbc"));
64
    println!("{}", Archiver::new(make_strategy("none")).store("aaabbbbc"));
65
}

Real output:

1
[rle] a3b4c1
2
[none] aaabbbbc

Detailed Explanation

Closures are the lightest strategy

In fn checkout(subtotal: f64, discount: impl Fn(f64) -> f64), the parameter type impl Fn(f64) -> f64 reads as “any value I can call with one f64 that gives back an f64.” That covers closures, function pointers, and fn items. There is no interface to declare and no class to write — the function signature is the strategy contract.

impl Fn in argument position is sugar for a generic: it is the same as fn checkout<F: Fn(f64) -> f64>(subtotal: f64, discount: F). So a closure argument is still static dispatch and gets inlined. The three closure traits express how the strategy uses its captured environment:

Fn — callable through a shared reference; can be called many times, captures by reference or copy. This is the common case for a stateless strategy.
FnMut — needs &mut self to run because it mutates captured state (e.g. a counter, an accumulator).
FnOnce — consumes captured values, so it can be called only once (e.g. a strategy that moves a String out of itself).

1
trait Renderer {
2
    fn render(&self) -> String;
3
}
4

5
struct Json;
6
impl Renderer for Json {
7
    fn render(&self) -> String {
8
        "{}".to_string()
9
    }
10
}
11

12
// A borrowed trait object: no heap allocation, no ownership transfer.
13
fn print_with(r: &dyn Renderer) {
14
    println!("{}", r.render());
15
}
16

17
fn main() {
18
    let json = Json;
19
    print_with(&json); // borrow as &dyn Renderer; no Box required
20

21
    // An FnMut strategy: it mutates captured state on each call.
22
    let mut count = 0;
23
    let mut tick = || {
24
        count += 1;
25
        count
26
    };
27
    println!("{} {} {}", tick(), tick(), tick());
28
}

Real output:

The percent_off/flat_off “closure that returns a closure” trick is how you parameterize a strategy by data — the equivalent of new PercentOff(0.1) in the TypeScript version, but the result is a function value rather than an object.

Generics fix the strategy at compile time

Field<V: Validator> is generic over the strategy. When you write Field::new("username", NonEmpty), the compiler creates a distinct Field<NonEmpty> type with the validate call hard-wired and inlinable. This is monomorphization — the same machinery behind impl Fn. There is no vtable, no indirection, and the optimizer can see through the call.

The trade-off: a Field<NonEmpty> and a Field<MaxLen> are different types. You cannot put both in one Vec<Field<_>> without erasing the difference, and the generic parameter spreads to everything that names the type. Generics are the right call when each context uses one strategy chosen at build time, and you want maximum speed.

Tip: This is exactly the opposite of TypeScript generics, which are erased at runtime. A TypeScript Field<V> is one runtime shape with V thrown away; a Rust Field<V> is many runtime shapes, one per V. See Section 09: Generic Functions.

Trait objects defer the choice to runtime

Box<dyn CompressionStrategy> stores some type implementing the trait, behind a pointer plus a vtable. The Archiver field has one concrete type (Box<dyn CompressionStrategy>) no matter which strategy is inside, so a single Archiver can hold NoCompression today and RunLength after a config reload. Calls like self.strategy.compress(...) look up the function in the vtable at runtime — dynamic dispatch, the same model JavaScript always uses.

You reach for dyn when the strategy is genuinely runtime-selected, when you need a heterogeneous collection (Vec<Box<dyn CompressionStrategy>>), or when the generic type parameter would otherwise leak across a large API surface. The cost is a pointer indirection per call and a missed inlining opportunity — usually negligible, occasionally measurable in hot loops.

You already use this pattern in std

The standard library is full of closure-as-strategy APIs. Vec::sort_by takes the comparison strategy as a closure; swapping the closure swaps the algorithm without touching the sort.

1
fn main() {
2
    let mut words = vec!["pear", "fig", "banana", "kiwi"];
3

4
    // Strategy 1: order by length.
5
    words.sort_by(|a, b| a.len().cmp(&b.len()));
6
    println!("{words:?}");
7

8
    // Strategy 2: reverse-alphabetical — just pass a different closure.
9
    words.sort_by(|a, b| b.cmp(a));
10
    println!("{words:?}");
11

12
    // sort_by_key takes a "key extraction" strategy.
13
    words.sort_by_key(|w| w.len());
14
    println!("{words:?}");
15
}

Real output:

1
["fig", "pear", "kiwi", "banana"]
2
["pear", "kiwi", "fig", "banana"]
3
["fig", "pear", "kiwi", "banana"]

Key Differences

Aspect	TypeScript (interface + classes)	Rust closures	Rust generics	Rust trait objects
Strategy is…	a class instance	a function value	a concrete type param	`Box<dyn Trait>` / `&dyn Trait`
Dispatch	dynamic (always)	static (inlined)	static (monomorphized)	dynamic (vtable)
Chosen at	runtime	compile or runtime	compile time	runtime
Heterogeneous collection	trivial (`Strategy[]`)	needs `Box<dyn Fn>`	not directly	trivial (`Vec<Box<dyn _>>`)
Extra methods / state	yes (class)	awkward (one fn)	yes (trait)	yes (trait)
Runtime cost	property lookup	none	none	pointer + vtable lookup
Boilerplate	high (a class each)	lowest	medium	medium

The decision tree most Rust developers use:

Is the strategy just one function? Use a closure (impl Fn / Box<dyn Fn>). This is the default; do not write a trait you do not need.
Does it have several methods or named state, and is it fixed per call site? Use a trait + generics (<S: Strategy>) for zero-cost static dispatch.
Is it selected at runtime, stored in a field, or mixed in a collection? Use a trait object (Box<dyn Strategy>).

Note: Rust having three encodings is not redundancy — it is the cost model made explicit. TypeScript hides every strategy behind one dynamic-dispatch mechanism. Rust makes you say whether the indirection is worth it.

The biggest mindset shift from TypeScript: do not start by writing an interface. In TypeScript an interface is the entry fee for any abstraction. In Rust the entry fee is a function type, and you only graduate to a trait when one function genuinely is not enough.

Common Pitfalls

Pitfall 1: putting two different closures in one `Vec` without boxing

Every closure has its own unique, unnameable type — even two closures with identical signatures are different types. So this does not compile:

1
fn main() {
2
    let pct = 0.10_f64;
3
    let amount = 10.0_f64;
4
    let percent = move |s: f64| s * (1.0 - pct);    // captures pct
5
    let flat = move |s: f64| (s - amount).max(0.0); // captures amount
6
    let strategies = vec![percent, flat]; // does not compile (error[E0308])
7
    for s in &strategies {
8
        println!("{}", s(100.0));
9
    }
10
}

The real compiler error is explicit about why:

1
error[E0308]: mismatched types
2
 --> src/main.rs:6:36
3
  |
4
4 |     let percent = move |s: f64| s * (1.0 - pct);   // captures pct
5
  |                   ------------- the expected closure
6
5 |     let flat = move |s: f64| (s - amount).max(0.0); // captures amount
7
  |                ------------- the found closure
8
6 |     let strategies = vec![percent, flat]; // two DISTINCT closure types
9
  |                                    ^^^^ expected closure, found a different closure
10
  |
11
  = note: expected closure `{closure@src/main.rs:4:19: 4:32}`
12
             found closure `{closure@src/main.rs:5:16: 5:29}`
13
  = note: no two closures, even if identical, have the same type
14
  = help: consider boxing your closure and/or using it as a trait object

The fix is exactly what the compiler suggests — box them into a uniform trait-object type:

1
fn main() {
2
    let pct = 0.10_f64;
3
    let amount = 10.0_f64;
4
    let strategies: Vec<Box<dyn Fn(f64) -> f64>> = vec![
5
        Box::new(move |s: f64| s * (1.0 - pct)),
6
        Box::new(move |s: f64| (s - amount).max(0.0)),
7
    ];
8
    for s in &strategies {
9
        println!("{:.2}", s(100.0));
10
    }
11
}

Real output:

Note: If neither closure captures anything, they can each coerce to the same fn(f64) -> f64 function-pointer type and the Vec compiles without boxing. The conflict appears the moment they capture different environments.

Pitfall 2: a strategy trait that cannot become a trait object

If you plan to use Box<dyn Strategy>, the trait must be dyn-compatible (historically “object-safe”). A generic method breaks that, because the compiler cannot put an infinite family of methods in one vtable:

1
trait Transformer {
2
    // A generic method makes the trait NOT dyn-compatible.
3
    fn transform<T: std::fmt::Display>(&self, value: T) -> String;
4
}
5

6
fn use_it(t: &dyn Transformer) { // does not compile (error[E0038])
7
    println!("{}", t.transform(42));
8
}

The real error names the exact reason:

1
error[E0038]: the trait `Transformer` is not dyn compatible
2
 --> src/main.rs:5:15
3
  |
4
5 | fn use_it(t: &dyn Transformer) {
5
  |               ^^^^^^^^^^^^^^^ `Transformer` is not dyn compatible
6
  |
7
note: for a trait to be dyn compatible it needs to allow building a vtable
8
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
9
 --> src/main.rs:2:8
10
  |
11
1 | trait Transformer {
12
  |       ----------- this trait is not dyn compatible...
13
2 |     fn transform<T: std::fmt::Display>(&self, value: T) -> String;
14
  |        ^^^^^^^^^ ...because method `transform` has generic type parameters
15
  = help: consider moving `transform` to another trait

Fixes: drop the generic (take &dyn Display instead of T), or keep the generic and use the strategy through generics rather than dyn. The detailed rules are in Section 09: Trait Objects.

Pitfall 3: reaching for a trait when a closure would do

The most common over-engineering mistake for a TypeScript developer is writing this in Rust:

1
trait DiscountStrategy {
2
    fn apply(&self, subtotal: f64) -> f64;
3
}
4
struct PercentOff(f64);
5
impl DiscountStrategy for PercentOff {
6
    fn apply(&self, subtotal: f64) -> f64 {
7
        subtotal * (1.0 - self.0)
8
    }
9
}
10
// ...and a struct + impl for every other rule.

If apply is the only method and the strategy carries no behavior beyond it, all of that collapses to impl Fn(f64) -> f64. Writing a one-method trait that exists only to be a strategy is usually a sign you wanted a closure. Reserve the trait for when there are multiple methods (apply and name and is_combinable) or when you need a named type to implement other traits.

Pitfall 4: assuming `dyn` is free like in TypeScript

In TypeScript every method call is already a dynamic lookup, so dyn-style dispatch feels like the natural baseline. In Rust the baseline is static dispatch, and Box<dyn Strategy> adds a heap allocation plus a per-call vtable indirection that prevents inlining. It is the right tool for runtime selection, but do not default to it for a strategy that is fixed at compile time — that throws away performance Rust gives you for free.

Best Practices

Default to closures. If the strategy is a single function, use impl Fn for arguments and Box<dyn Fn> only when you must store or collect heterogeneous functions.
Promote to a trait when behavior is richer than one call. Multiple methods, associated constants, or a strategy that must also be Debug/Clone all justify a trait.
Use generics for compile-time choice, dyn for runtime choice. Phrase it as a question: “Does the caller know the concrete strategy at the call site?” Yes → generic. No → trait object.
Accept &dyn Trait over Box<dyn Trait> in function arguments when you only need to borrow the strategy — it avoids forcing the caller to allocate.
Keep strategy traits dyn-compatible if you might box them — avoid generic methods and Self-returning methods unless you commit to generics only.
Pair the strategy with a factory for runtime selection: a fn make_strategy(name: &str) -> Box<dyn Strategy> keeps the match over config strings in one place (see factory-pattern.md).
Let a blanket impl bridge closures and traits. impl<F: Fn(&str) -> String> Transform for F {} lets callers pass either a struct strategy or a bare closure to the same generic API — the best of both worlds.

Real-World Example

A request router whose load-balancing policy is chosen at startup from configuration. The policy genuinely varies at runtime and has more than one method, so this is the case where a trait object is the right call — and it shows the strategy, context, and factory working together.

1
use std::collections::HashMap;
2

3
/// The strategy: how to pick a backend for a request.
4
trait LoadBalancer {
5
    fn pick(&self, backends: usize, request_no: u64) -> usize;
6
    fn name(&self) -> &'static str;
7
}
8

9
struct RoundRobin;
10
struct Sticky {
11
    /// Pin every request to one backend (e.g. for a canary rollout).
12
    index: usize,
13
}
14

15
impl LoadBalancer for RoundRobin {
16
    fn pick(&self, backends: usize, request_no: u64) -> usize {
17
        (request_no as usize) % backends
18
    }
19
    fn name(&self) -> &'static str {
20
        "round-robin"
21
    }
22
}
23

24
impl LoadBalancer for Sticky {
25
    fn pick(&self, _backends: usize, _request_no: u64) -> usize {
26
        self.index
27
    }
28
    fn name(&self) -> &'static str {
29
        "sticky"
30
    }
31
}
32

33
/// The context holds a boxed strategy chosen at startup.
34
struct Router {
35
    backends: Vec<String>,
36
    strategy: Box<dyn LoadBalancer>,
37
}
38

39
impl Router {
40
    fn new(backends: Vec<String>, strategy: Box<dyn LoadBalancer>) -> Self {
41
        Router { backends, strategy }
42
    }
43

44
    fn route(&self, request_no: u64) -> &str {
45
        let i = self.strategy.pick(self.backends.len(), request_no);
46
        &self.backends[i]
47
    }
48
}
49

50
/// A factory mapping a config string to a concrete strategy.
51
fn strategy_from_config(cfg: &str) -> Box<dyn LoadBalancer> {
52
    match cfg {
53
        "sticky" => Box::new(Sticky { index: 0 }),
54
        _ => Box::new(RoundRobin),
55
    }
56
}
57

58
fn main() {
59
    let backends = vec![
60
        "10.0.0.1".to_string(),
61
        "10.0.0.2".to_string(),
62
        "10.0.0.3".to_string(),
63
    ];
64

65
    let config: HashMap<&str, &str> = HashMap::from([("lb", "round-robin")]);
66
    let router = Router::new(backends.clone(), strategy_from_config(config["lb"]));
67

68
    println!("policy: {}", router.strategy.name());
69
    for req in 0..5 {
70
        println!("request {req} -> {}", router.route(req));
71
    }
72

73
    // Swapping policies is just swapping the boxed strategy — the classic pattern.
74
    let canary = Router::new(backends, strategy_from_config("sticky"));
75
    println!("\npolicy: {}", canary.strategy.name());
76
    for req in 0..3 {
77
        println!("request {req} -> {}", canary.route(req));
78
    }
79
}

Real output:

1
policy: round-robin
2
request 0 -> 10.0.0.1
3
request 1 -> 10.0.0.2
4
request 2 -> 10.0.0.3
5
request 3 -> 10.0.0.1
6
request 4 -> 10.0.0.2
7

8
policy: sticky
9
request 0 -> 10.0.0.1
10
request 1 -> 10.0.0.1
11
request 2 -> 10.0.0.1

This compiles cleanly under cargo clippy with no warnings. If the policy were instead fixed per deployment and you cared about inlining pick in a hot path, you would make Router generic — Router<L: LoadBalancer> — and drop the Box.

Exercises

Exercise 1: a discount engine with closures

Difficulty: Easy

Objective: Implement the strategy pattern with closures — no trait, no struct.

Instructions: Write a function total_price(items: &[f64], discount: impl Fn(f64) -> f64) -> f64 that sums the items, applies the discount strategy to the subtotal, and rounds to two decimal places. In main, define three closure strategies — no discount, ten percent off, and five dollars off (never below zero) — and print the total for the cart [19.99, 5.00, 49.99] under each.

1
fn total_price(items: &[f64], discount: impl Fn(f64) -> f64) -> f64 {
2
    // TODO: sum the items, apply discount, round to 2 dp
3
    /* ??? */
4
}
5

6
fn main() {
7
    let cart = [19.99, 5.00, 49.99];
8
    // TODO: three closure strategies and a println! for each
9
}

Solution

1
fn total_price(items: &[f64], discount: impl Fn(f64) -> f64) -> f64 {
2
    let subtotal: f64 = items.iter().sum();
3
    let discounted = discount(subtotal);
4
    (discounted * 100.0).round() / 100.0
5
}
6

7
fn main() {
8
    let cart = [19.99, 5.00, 49.99];
9

10
    let no_discount = |s: f64| s;
11
    let ten_percent = |s: f64| s * 0.90;
12
    let five_off = |s: f64| (s - 5.0).max(0.0);
13

14
    println!("{:.2}", total_price(&cart, no_discount));
15
    println!("{:.2}", total_price(&cart, ten_percent));
16
    println!("{:.2}", total_price(&cart, five_off));
17
}

Real output:

Exercise 2: a runtime-selected hash strategy

Difficulty: Medium

Objective: Use trait objects to select a strategy at runtime from a registry.

Instructions: Define a trait HashStrategy with fn hash(&self, input: &str) -> u64. Implement it for SumBytes (sum of byte values) and Fnv1a (the FNV-1a algorithm). Build a Hasher whose field is a HashMap<String, Box<dyn HashStrategy>> populated with "sum" and "fnv". Add fn hash_with(&self, algo: &str, input: &str) -> Option<u64> that looks up the strategy by name and applies it, returning None for an unknown algorithm.

Solution

1
use std::collections::HashMap;
2

3
trait HashStrategy {
4
    fn hash(&self, input: &str) -> u64;
5
}
6

7
struct SumBytes;
8
struct Fnv1a;
9

10
impl HashStrategy for SumBytes {
11
    fn hash(&self, input: &str) -> u64 {
12
        input.bytes().map(u64::from).sum()
13
    }
14
}
15

16
impl HashStrategy for Fnv1a {
17
    fn hash(&self, input: &str) -> u64 {
18
        let mut h: u64 = 0xcbf29ce484222325;
19
        for b in input.bytes() {
20
            h ^= u64::from(b);
21
            h = h.wrapping_mul(0x100000001b3);
22
        }
23
        h
24
    }
25
}
26

27
struct Hasher {
28
    registry: HashMap<String, Box<dyn HashStrategy>>,
29
}
30

31
impl Hasher {
32
    fn new() -> Self {
33
        let mut registry: HashMap<String, Box<dyn HashStrategy>> = HashMap::new();
34
        registry.insert("sum".to_string(), Box::new(SumBytes));
35
        registry.insert("fnv".to_string(), Box::new(Fnv1a));
36
        Hasher { registry }
37
    }
38

39
    fn hash_with(&self, algo: &str, input: &str) -> Option<u64> {
40
        self.registry.get(algo).map(|s| s.hash(input))
41
    }
42
}
43

44
fn main() {
45
    let hasher = Hasher::new();
46
    println!("{:?}", hasher.hash_with("sum", "abc"));
47
    println!("{:?}", hasher.hash_with("fnv", "abc"));
48
    println!("{:?}", hasher.hash_with("missing", "abc"));
49
}

Real output:

1
Some(294)
2
Some(16654208175385433931)
3
None

Exercise 3: a generic pipeline that also accepts closures

Difficulty: Hard

Objective: Combine the generic and closure encodings with a blanket impl so one API accepts both struct strategies and bare closures.

Instructions: Define a trait Transform with fn apply(&self, input: &str) -> String. Implement it for unit structs Upper (uppercase the input) and Reverse (reverse the characters). Then add a blanket impl impl<F: Fn(&str) -> String> Transform for F so any matching closure is also a Transform. Make a generic Pipeline<T: Transform> with a run(&self, input: &str) -> String method, and drive it with Upper, Reverse, and a closure |s: &str| format!("{s}!").

Solution

1
trait Transform {
2
    fn apply(&self, input: &str) -> String;
3
}
4

5
struct Upper;
6
struct Reverse;
7

8
impl Transform for Upper {
9
    fn apply(&self, input: &str) -> String {
10
        input.to_uppercase()
11
    }
12
}
13

14
impl Transform for Reverse {
15
    fn apply(&self, input: &str) -> String {
16
        input.chars().rev().collect()
17
    }
18
}
19

20
// Any matching closure is ALSO a Transform, so callers can pass either.
21
impl<F: Fn(&str) -> String> Transform for F {
22
    fn apply(&self, input: &str) -> String {
23
        self(input)
24
    }
25
}
26

27
struct Pipeline<T: Transform> {
28
    transform: T,
29
}
30

31
impl<T: Transform> Pipeline<T> {
32
    fn run(&self, input: &str) -> String {
33
        self.transform.apply(input)
34
    }
35
}
36

37
fn main() {
38
    let upper = Pipeline { transform: Upper };
39
    let reverse = Pipeline { transform: Reverse };
40
    let exclaim = Pipeline { transform: |s: &str| format!("{s}!") };
41

42
    println!("{}", upper.run("hello"));
43
    println!("{}", reverse.run("hello"));
44
    println!("{}", exclaim.run("hello"));
45
}

Real output:

1
HELLO
2
olleh
3
hello!

Note: A blanket impl over F: Fn(...) is powerful but can conflict if you later add another blanket impl that could also match the same types. Keep one such bridge per trait.

The Strategy Pattern in Rust

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Version 1: plain closures (the idiomatic default)

Version 2: generics (compile-time strategy, zero-cost)

Version 3: trait objects (runtime strategy, the OO shape)

Detailed Explanation

Closures are the lightest strategy

Generics fix the strategy at compile time

Trait objects defer the choice to runtime

You already use this pattern in std

Key Differences

Common Pitfalls

Pitfall 1: putting two different closures in one `Vec` without boxing

Pitfall 2: a strategy trait that cannot become a trait object

Pitfall 3: reaching for a trait when a closure would do

Pitfall 4: assuming `dyn` is free like in TypeScript

Best Practices

Real-World Example

Further Reading

Official documentation

Exercises

Exercise 1: a discount engine with closures

Exercise 2: a runtime-selected hash strategy

Exercise 3: a generic pipeline that also accepts closures

The Strategy Pattern in Rust

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Version 1: plain closures (the idiomatic default)

Version 2: generics (compile-time strategy, zero-cost)

Version 3: trait objects (runtime strategy, the OO shape)

Detailed Explanation

Closures are the lightest strategy

Generics fix the strategy at compile time

Trait objects defer the choice to runtime

You already use this pattern in std

Key Differences

Common Pitfalls

Pitfall 1: putting two different closures in one Vec without boxing

Pitfall 2: a strategy trait that cannot become a trait object

Pitfall 3: reaching for a trait when a closure would do

Pitfall 4: assuming dyn is free like in TypeScript

Best Practices

Real-World Example

Further Reading

Official documentation

Related topics in this guide

Exercises

Exercise 1: a discount engine with closures

Exercise 2: a runtime-selected hash strategy

Exercise 3: a generic pipeline that also accepts closures

Pitfall 1: putting two different closures in one `Vec` without boxing

Pitfall 4: assuming `dyn` is free like in TypeScript