C#策略模式Context类疑问：为何构造函数传入Strategy后重新赋值

对应设计模式概念 #

这段代码是**策略模式（Strategy Pattern）**的核心实现片段，策略模式是经典的行为型设计模式，核心设计思路是将一族可互相替换的算法（或业务规则）封装为独立的策略类，让算法的定义、实现和使用算法的客户端逻辑完全解耦，二者可以独立变更而不互相影响。

你给出的代码属于策略模式里的*上下文（Context）*角色，这个角色的定位是调度者，不实现任何具体算法逻辑，只负责对接策略实例、对外提供统一的调用入口：

• 代码中的Strategy是抽象策略的基类或接口，约定了所有具体策略必须实现的AlgorithmInterface()方法
• 外部调用方只需要调用Context提供的ContextInterface()方法即可，不需要感知底层具体策略的实现细节，也不需要关心策略的执行过程
• 所有继承/实现了Strategy的具体策略类，都可以无缝替换使用

对应完整示例代码如下：

public class Context
{
    Strategy strategy;
    // 构造函数
    public Context(Strategy strategy)
    {
        this.strategy = strategy;
    }
    public void ContextInterface()
    {
        strategy.AlgorithmInterface();
    }
}

构造函数传入并赋值strategy的原因 #

这么设计的核心目的是贴合策略模式的设计目标，同时保障代码的可维护性和健壮性，具体原因如下：

• 实现策略的灵活可替换：把策略的选择权完全交给外部调用方，Context本身不需要硬编码绑定具体策略，需要用哪种策略就传入对应策略的实例即可，后续要更换策略只需要修改传入的参数，不需要改动Context的内部代码，符合开闭原则
• 解耦上下文和具体策略：Context只依赖抽象的Strategy约定，不依赖任何具体的策略实现类，只要满足Strategy接口规范的实现都可以传入使用，二者可以独立迭代，修改策略逻辑完全不会影响Context的调度代码
• 保障运行时安全：在构造阶段就完成策略实例的注入，能保证调用ContextInterface()执行算法时，内部的strategy成员已经完成初始化，避免出现空引用异常
• 符合单一职责原则：Context的职责仅为调度策略执行，不需要负责策略对象的创建、销毁逻辑，策略的实例化由外部业务逻辑按需处理，每个类的职责边界更清晰，后续维护成本更低

内容的提问来源于stack exchange，提问作者Rafhi