1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 反例：折扣计算，每加一种活动就往这里塞
public decimal CalculateDiscount(string type, decimal price)
{
    return type switch
    {
        "Normal"    => price,                    // 不打折
        "Vip"       => price * 0.8m,             // VIP 八折
        "Coupon"    => price - 50m,              // 满减券
        "Employee"  => price * 0.5m,             // 员工五折
        _ => price
    };
}

1
2
3
4
5
6
7

这坨代码的病：
  ✗ 违反开闭原则：加"双11满3件打7折"要改这个方法（动老代码）
  ✗ 越长越难维护，分支互相影响
  ✗ 算法全堆一处，没法单独复用/测试
  ✗ DiscountService 依赖了所有折扣细节

  病根：把"选择哪个算法"和"算法本身"搅在一起了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

意图：定义一系列算法，各自封装，可互相替换。
     算法的变化不影响使用它的客户端。

  结构：
    IStrategy        ← 算法的抽象接口
    ConcreteStrategy  ← 每个算法一个实现
    Context          ← 持有某个策略，把工作委托给它

  好处：
    ✓ 新增算法 = 加一个类，老代码不动（开闭）
    ✓ 算法可单独测试、复用
    ✓ 客户端不关心算法细节，只管"调它"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// 1. 策略接口
public interface IDiscountStrategy
{
    decimal Apply(decimal price);
}

// 2. 每个算法一个实现
public class NormalDiscount : IDiscountStrategy
{
    public decimal Apply(decimal price) => price;
}
public class VipDiscount : IDiscountStrategy
{
    public decimal Apply(decimal price) => price * 0.8m;
}
public class EmployeeDiscount : IDiscountStrategy
{
    public decimal Apply(decimal price) => price * 0.5m;
}

// 3. Context：把"算折扣"委托给注入进来的策略
public class PricingService(IDiscountStrategy _discount)
{
    public decimal GetFinalPrice(decimal price) => _discount.Apply(price);
}

1
2

现在加"双11折扣"：写一个 DoubleElevenDiscount 类，
PricingService 一行不用改 → 开闭原则达成。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 策略就是一个函数
public class PricingService
{
    private readonly Func<decimal, decimal> _discount;

    public PricingService(Func<decimal, decimal> discount) => _discount = discount;

    public decimal GetFinalPrice(decimal price) => _discount(price);
}

// 注册时直接传 lambda（配合 DI）
services.AddTransient<PricingService>(_ => new PricingService(p => p * 0.8m));  // VIP

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

public class DiscountCalculator
{
    // 字典：type → 算法函数
    private readonly Dictionary<string, Func<decimal, decimal>> _strategies = new()
    {
        ["Normal"]   = p => p,
        ["Vip"]      = p => p * 0.8m,
        ["Coupon"]   = p => Math.Max(0, p - 50m),
        ["Employee"] = p => p * 0.5m,
    };

    public decimal Calculate(string type, decimal price)
        => _strategies.TryGetValue(type, out var fn) ? fn(price) : price;
}

1
2
3
4
5
6
7

对比开头的 switch：
  - 加新折扣 = 字典加一行，方法体不动
  - 算法集中、清晰、可测
  - 没有多余的类层次，但拿到了策略模式的所有好处

  这就是 .NET 里策略模式的现代写法——
  "意图"没变（算法族可替换），"实现"从类层次简化成函数。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

你天天在用策略模式，只是没意识到：

  LINQ：
    list.OrderBy(x => x.Name)    // x => x.Name 就是一个"排序策略"
    list.Where(x => x.Active)    // 过滤策略
    → 同样的 OrderBy，传不同 keySelector = 不同策略，框架替你 dispatch

  集合比较：
    new SortedSet<int>(Comparer<int>.Create((a, b) => b - a))  // 降序比较策略

  ASP.NET Core：
    config.AddJsonFile() / .AddEnvironmentVariables()  // 每个"配置源"都是策略
    serializer options：不同的命名策略、枚举转换策略

  Task.Run / Parallel.ForEach 的并行度策略、
  EF Core 的值比较器（IEqualityComparer<T>）……

  本质都是：把"可替换的一段逻辑"作为参数传进去。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

用类（IDiscountStrategy 接口 + 实现）：
  ✓ 算法复杂、有状态、需要注入依赖（VIP 折扣要查用户等级）
  ✓ 多处复用、需要独立测试某个算法
  ✓ 团队习惯显式类型

用函数（Func / delegate / 字典）：
  ✓ 算法简单、无状态、就几行
  ✓ 想轻量，不想为一小段逻辑建一堆类
  ✓ 动态组合（字典派发、运行时拼装）

  经验：简单用函数，复杂用类。
       别为了"显得正规"给三行 lambda 套个接口。
       （第一条讲的 YAGNI）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

该用策略模式：
  ✓ 一组同类算法，按条件选一个（折扣/支付/排序/校验…）
  ✓ 算法会随业务不断新增
  ✓ 想把选择逻辑和算法实现分开

别用：
  ✗ 只有一两种情况，if/switch 清清楚楚 → 别过度设计
  ✗ 分支不是"选算法"，而是"按数据走不同流程" → 那是状态/责任链的活
  ✗ 算法之间共享大量状态、关系紧密 → 硬拆成策略反而更乱

  信号：当 switch 分支多到让你皱眉、新增分支让你害怕，
       就是策略模式该上场的时候。