在C#项目里，算法切换最常见的坏味道就是满屏的if-else或者switch语句，每加一种计算规则就要动核心方法。策略模式（Strategy）把每一种可互换的算法封装成实现了相同接口的类，让调用方依赖抽象而非具体实现，从而在运行时动态替换行为。这种结构不仅符合开闭原则，也让单一职责更加清晰。
策略模式的核心结构与C#接口抽象
策略模式的本质是把“做什么”和“怎么做”分离。在C#中，我们首先定义一个算法接口，比如IStrategy，里面只声明一个执行方法。所有具体算法，如加法策略、乘法策略或者压缩策略，都实现这个接口。上下文类（Context）持有一个IStrategy类型的字段，并通过构造函数或者属性接收外部传入的具体策略对象。
这种抽象带来的直接好处是：调用方根本不需要知道背后运行的是哪一种算法。假设我们有一个报表导出功能，导出格式可能是Excel、PDF或者CSV，如果不用策略模式，代码里会出现大量条件判断；而使用接口抽象后，只需定义IExportStrategy，然后提供ExcelExport、PdfExport等类即可。下面是一段基础的接口与上下文定义代码：
public interface IStrategy
{
int Compute(int a, int b);
}
public class AddStrategy : IStrategy
{
public int Compute(int a, int b)
{
return a + b;
}
}
public class MultiplyStrategy : IStrategy
{
public int Compute(int a, int b)
{
return a * b;
}
}
public class Context
{
private readonly IStrategy _strategy;
public Context(IStrategy strategy)
{
_strategy = strategy;
}
public int Execute(int a, int b)
{
return _strategy.Compute(a, b);
}
}
从上述代码可以看到，Context完全不关心Compute的内部逻辑，它只负责把参数透传给当前策略。如果以后要新增一个取模算法，只需要新建一个实现IStrategy的类，原有上下文和调用代码一行都不用改。这就是策略模式在C#里最基础的落地方式，也是消除分支爆炸的第一步。
在实战中动态切换算法与依赖注入
真实业务里，算法往往不是写死在代码里的，而是根据用户配置、请求参数或者环境变量来决定。在ASP.NET Core应用中，我们可以借助内置的依赖注入容器来管理各种策略。做法是把所有的具体策略都注册为IStrategy的服务，然后使用工厂或者IEnumerable<IStrategy>来按名称获取实例。这样控制器里就不需要new具体类，进一步降低耦合。
举个例子，一个电商促销系统支持满减、折扣、拼团三种计算方式。我们可以让每个策略类带上一个StrategyName属性，在工厂里遍历已注入的策略集合，匹配到对应名称就返回。调用方只需传入“discount”这样的字符串，就能拿到正确的算法对象。下面演示一个简单工厂配合注入的写法：
public interface IStrategy
{
string Name { get; }
decimal Calculate(decimal price);
}
public class FullReductionStrategy : IStrategy
{
public string Name ="full";
public decimal Calculate(decimal price)
{
return price >= 100 ? price - 20 : price;
}
}
public class DiscountStrategy : IStrategy
{
public string Name ="discount";
public decimal Calculate(decimal price)
{
return price * 0.9m;
}
}
public class StrategyFactory
{
private readonly IEnumerable<IStrategy> _strategies;
public StrategyFactory(IEnumerable<IStrategy> strategies)
{
_strategies = strategies;
}
public IStrategy Get(string name)
{
return _strategies.FirstOrDefault(s => s.Name == name)
?? throw new ArgumentException("未找到对应策略");
}
}
这种写法在扩展时非常舒服：新增一种促销，只需新建类并在Startup里AddScoped<IStrategy, NewStrategy>()，工厂自动就能发现它。相比在switch里不断加case，维护成本直线下降。同时因为策略各自独立，单元测试时可以针对单个类写用例，不必启动整个上下文。
用委托与泛型让策略模式更轻量
C#作为支持一等公民函数的语言，并不一定非要用类和接口才能表达策略。对于逻辑很短的算法，我们可以直接用Func<T, TResult>委托来替代接口，从而减少类文件数量。再配合泛型上下文，就能写出既类型安全又极度简洁的切换逻辑。这种方式在算法结构简单、复用要求不高的内部工具里特别合适。
例如排序场景，我们想根据外部开关在“按价格”和“按销量”之间切换，直接传Func<Product, object>给排序方法就行。如果担心裸委托不利于统一管理，还可以用泛型Strategy<T>包装一下，内部依然存委托。下面的代码展示泛型上下文配合委托的用法：
public class Strategy<TInput, TOutput>
{
private readonly Func<TInput, TOutput> _func;
public Strategy(Func<TInput, TOutput> func)
{
_func = func;
}
public TOutput Execute(TInput input)
{
return _func(input);
}
}
var add = new Strategy<int, int>(x => x + 10);
var multiply = new Strategy<int, int>(x => x * 2);
int result = add.Execute(5);
委托策略的短板在于：当算法需要维护状态或者包含多个方法时，还是回归接口类更清晰。所以实际项目中常常是“重策略用接口，轻策略用委托”的混合模式。理解这两种形态，你就能在C#里根据场景自由选用，既不让代码膨胀，也不让结构失控。策略模式不是银弹，但掌握它在算法切换上的实战技巧，绝对能让你的C#架构干净一个档次。