ASP.NET Core微服务中策略模式下基类参数具体类型的安全实现方案问询

你的场景很典型：在构建完聚合上下文后，策略需要基于已知的判定属性操作具体子类，但又不想用强制转换破坏抽象。下面是几种安全且符合OOP原则的解决方案，你可以根据自己的架构偏好选择：

1. 访问者模式（Visitor Pattern） #

访问者模式是处理这种"基类持有，需要操作子类"场景的经典方案，它能让你在不修改上下文类的前提下（或者只做最小修改），安全地访问子类专属数据。

实现步骤： #

首先定义访问者接口，包含针对每个具体上下文子类的处理方法：

public interface IContextVisitor
{
    Task Visit(ConcreteContextA1 contextA);
    Task Visit(ConcreteContextA2 contextA);
    Task Visit(ConcreteContextB1 contextB);
    Task Visit(ConcreteContextB2 contextB);
    // 其他子类对应的方法
}

然后在上下文基类中添加抽象的Accept方法，子类实现该方法并将自己传递给访问者：

// OtherContextA基类
public abstract class OtherContextA
{
    public abstract Task Accept(IContextVisitor visitor);
}

// 具体子类示例
public class ConcreteContextA1 : OtherContextA
{
    // 子类专属字段
    public string SpecificFieldA1 { get; set; }

    public override Task Accept(IContextVisitor visitor)
    {
        return visitor.Visit(this);
    }
}

// OtherContextB基类同理
public abstract class OtherContextB
{
    public abstract Task Accept(IContextVisitor visitor);
}

最后，让你的策略类实现IContextVisitor接口，这样在策略中就能直接处理具体子类，完全不需要强制转换：

public class ConcreteStrategy : StrategyInterface, IContextVisitor
{
    public async Task ProcessContext(MainContext mainContext)
    {
        // 直接调用Accept，自动路由到对应子类的Visit方法
        await mainContext.ContextA.Accept(this);
        await mainContext.ContextB.Accept(this);
    }

    public async Task Visit(ConcreteContextA1 contextA)
    {
        // 直接使用contextA的专属字段，无需转换
        Console.WriteLine(contextA.SpecificFieldA1);
        // 执行该子类对应的业务逻辑
    }

    // 实现其他Visit方法处理不同子类
    public async Task Visit(ConcreteContextA2 contextA) { /* ... */ }
    public async Task Visit(ConcreteContextB1 contextB) { /* ... */ }
    public async Task Visit(ConcreteContextB2 contextB) { /* ... */ }
}

优点：完全避免强制转换，符合开闭原则（新增子类只需添加对应的Visit方法和子类实现）；逻辑分离清晰，策略专注于处理逻辑，上下文专注于数据持有。
缺点：如果子类数量较多，访问者接口会比较庞大；需要修改上下文基类和子类，对现有代码有一定侵入性。

2. 泛型策略+类型匹配工厂 #

另一种思路是让策略与具体的上下文类型绑定，通过工厂根据DeterminerAttribute来匹配并创建对应的泛型策略，这样策略可以直接拿到强类型的上下文实例。

实现步骤： #

首先定义泛型策略接口：

public interface IStrategy<TContextA, TContextB> 
    where TContextA : OtherContextA
    where TContextB : OtherContextB
{
    Task ProcessContext(TContextA contextA, TContextB contextB);
}

然后实现具体的泛型策略，直接使用子类专属字段：

public class StrategyForCaseX : IStrategy<ConcreteContextA1, ConcreteContextB2>
{
    public async Task ProcessContext(ConcreteContextA1 contextA, ConcreteContextB2 contextB)
    {
        // 直接使用子类专属数据
        var combinedData = contextA.SpecificFieldA1 + contextB.SpecificFieldB2;
        // 执行业务逻辑
    }
}

接下来创建策略工厂，根据DeterminerAttribute来解析并返回对应的泛型策略：

public class StrategyFactory
{
    private readonly IServiceProvider _serviceProvider;

    public StrategyFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public async Task ExecuteStrategy(MainContext mainContext)
    {
        // 根据DeterminerAttribute匹配对应的泛型策略类型
        Type strategyType = mainContext.Attribute switch
        {
            DeterminerAttribute.CaseX => typeof(IStrategy<ConcreteContextA1, ConcreteContextB2>),
            DeterminerAttribute.CaseY => typeof(IStrategy<ConcreteContextA2, ConcreteContextB1>),
            // 其他case
            _ => throw new InvalidOperationException("Unknown determiner")
        };

        // 从DI容器获取策略实例
        var strategy = _serviceProvider.GetService(strategyType);
        if (strategy == null)
            throw new InvalidOperationException("Strategy not registered");

        // 通过dynamic简化调用，避免复杂反射
        dynamic dynamicStrategy = strategy;
        await dynamicStrategy.ProcessContext((dynamic)mainContext.ContextA, (dynamic)mainContext.ContextB);
    }
}

优点：策略与具体上下文强绑定，代码更直观；无需修改现有上下文类，侵入性低。
缺点：依赖工厂的类型匹配逻辑，新增case时需要同步更新工厂；使用dynamic会损失部分编译时类型检查（但因为你是基于已知的DeterminerAttribute匹配，运行时安全有保障）。

3. 将处理逻辑内聚到上下文子类 #

如果业务逻辑与上下文数据的关联性很强，可以考虑把原本在策略中的操作内聚到上下文子类中，基类定义抽象方法，子类实现具体逻辑。这样策略只需要调用基类的抽象方法，完全不需要关心具体类型。

实现示例： #

修改上下文基类，添加抽象处理方法：

public abstract class OtherContextA
{
    public abstract Task Process();
}

public class ConcreteContextA1 : OtherContextA
{
    public string SpecificFieldA1 { get; set; }

    public override async Task Process()
    {
        // 该子类专属的处理逻辑
        await DoSomethingWithSpecificField(SpecificFieldA1);
    }
}

然后策略类只需调用基方法：

public class GenericStrategy : StrategyInterface
{
    public async Task ProcessContext(MainContext mainContext)
    {
        await mainContext.ContextA.Process();
        await mainContext.ContextB.Process();
    }
}

优点：完全消除类型转换，代码极简；符合单一职责原则（上下文自己负责处理自己的数据）。
缺点：如果处理逻辑涉及多个上下文的协作，或者需要外部依赖（比如其他服务、仓储），这种方式会让上下文类变得臃肿，违背关注点分离。

4. 强类型MainContext变体 #

如果你的DeterminerAttribute对应的上下文组合是固定的，可以创建不同的强类型MainContext子类，每个子类持有具体的上下文类型，然后策略针对不同的MainContext子类实现。

实现示例： #

// 基类保持抽象
public abstract class MainContextBase
{
    public DeterminerAttribute Attribute { get; set; }
}

// 对应CaseX的强类型MainContext
public class MainContextForCaseX : MainContextBase
{
    public ConcreteContextA1 ContextA { get; set; }
    public ConcreteContextB2 ContextB { get; set; }
}

// 对应CaseY的强类型MainContext
public class MainContextForCaseY : MainContextBase
{
    public ConcreteContextA2 ContextA { get; set; }
    public ConcreteContextB1 ContextB { get; set; }
}

然后策略可以通过重载来处理不同的MainContext：

public interface IStrategy
{
    Task Process(MainContextForCaseX context);
    Task Process(MainContextForCaseY context);
}

public class ConcreteStrategy : IStrategy
{
    public async Task Process(MainContextForCaseX context)
    {
        // 直接访问具体子类字段
        Console.WriteLine(context.ContextA.SpecificFieldA1);
    }

    public async Task Process(MainContextForCaseY context)
    {
        Console.WriteLine(context.ContextA.SpecificFieldA2);
    }
}

优点：编译时完全类型安全，没有任何转换；代码可读性极高。
缺点：如果DeterminerAttribute对应的组合很多，会产生大量的MainContext子类；构建MainContext时需要创建对应子类的实例，增加了构建逻辑的复杂度。

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