c#如何实现策略模式_c#策略模式完整教程与实战案例

策略模式在C#里不是靠“学完教程”就能用好的，关键之处在于接口是否真正隔离了变化点，上下文是否真的只依赖抽象——多数人写崩，是因为把具体策略的创建逻辑直接塞进了Context类里。说几个核心判断：接口只声明行为契约，Context仅持有并调用策略，依赖注入（DI）负责生命周期管理。下面逐条拆解。

如何定义IStrategy接口才不踩坑

接口不能暴露具体实现细节，对吧？比如，别在里面放ConnectionString或ApiKey这类配置字段；它唯一该做的是声明行为契约。常见错误是把策略当成了配置容器，结果每次加个新策略就得改接口，开闭原则瞬间被打破。

• 只保留一个核心方法，比如Execute()，或者带明确语义的名称（CalculateDiscount()、ValidateInput()）
• 参数尽量用DTO或基础类型，避免传HttpContext、IServiceProvider这类框架强依赖对象
• 返回值统一用Result或自定义状态类，别混用bool + out string——这种混搭在后期维护时简直是噩梦

Context类最容易写错的三件事

Context不是策略工厂，也不是策略缓存器，它的唯一职责就是持有并调用当前策略。很多人在这里偷偷耦合了创建逻辑或条件判断，结果单元测试时无法注入不同策略，测试就成了摆设。

• 构造函数只接收IStrategy，不接收Type、string name或配置节对象
• 禁止在Context内部new具体策略（比如new SqlPaymentStrategy()），这会让策略变成不可替换的硬编码
• 如果需要运行时切换策略，用属性或方法注入（SetStrategy(IStrategy s)），而不是在Execute里写if-else拿配置决定用哪个——那等于把策略模式退化成了条件分支

.NET 6+中用DI替代手动new策略实例

硬编码new策略不仅难测，还会让生命周期失控——比如本该是Scoped的策略被当成Singleton用，结果出现莫名其妙的状态共享问题。交给DI容器管理是最自然的解法。

注册方式示例：

services.AddScoped();
services.AddScoped();
// 或用Keyed Services（.NET 8+）
services.AddKeyedScoped("email", sp => new EmailNotificationStrategy());
services.AddKeyedScoped("sms", sp => new SmsNotificationStrategy());

使用时直接从IServiceProvider解析，或通过工厂封装：

• 用IServiceProvider.GetRequiredService()适合简单场景
• 需要多策略共存时，推荐工厂接口IStrategyFactory，内部根据key返回对应实例
• 必须警惕的是：Scoped策略在后台服务中可能提前释放，得用IServiceScopeFactory创建新scope

实战中策略命名和边界常被忽略

真实项目里，策略类名往往暴露了技术选型（比如RedisCacheStrategy），但业务方真正关心的是“什么时候用它”，而不是“底层用了什么技术”。命名应体现意图而非实现，否则换掉Redis改用MemoryCache时，你就得重命名所有引用点，那工作量可不小。

• 用业务语义命名：把FileExportStrategy改成HighVolumeDataExportStrategy，把ApiRateLimitStrategy改成PartnerTierRateLimitStrategy——这样一看就知道它在什么场景下生效
• 每个策略类只做一件事，不要在CalculateTax()里顺手发日志或调第三方API——那是装饰器或管道该干的活
• 策略间禁止互相调用，也不该共享状态字段（静态变量、单例服务中的可变字段）——共享状态是并发Bug的温床

最麻烦的不是写不出策略模式，而是后期维护时发现某个策略悄悄改了全局配置，或者Context被迫承担了路由、缓存、重试等本不属于它的责任。这才是真正的技术债。