如何从仅含请求的IWorker接口派生带请求与响应的接口？

方案一：显式接口实现+new关键字（解决方法签名冲突） #

这种方式直接沿用你最初的接口继承设计，通过new关键字声明带返回值的DoWork方法，再用显式接口实现处理基接口的无返回方法，既保持继承关系，又避免调用歧义。

接口定义 #

public interface IWorker<TRequest>
{
    Task DoWork(TRequest request);
}

public interface IWorker<TRequest, TResponse> : IWorker<TRequest>
{
    // 用new标记此方法覆盖基接口的同名方法（仅接口层面的声明）
    new Task<TResponse> DoWork(TRequest request);
}

实现类示例 #

public class OrderWorker : IWorker<OrderRequest, OrderResponse>
{
    // 显式实现基接口的无返回DoWork，内部调用带返回的版本并忽略结果
    async Task IWorker<OrderRequest>.DoWork(OrderRequest request)
    {
        await DoWork(request);
    }

    // 实现带返回值的DoWork，作为对外的核心逻辑方法
    public async Task<OrderResponse> DoWork(OrderRequest request)
    {
        // 执行业务逻辑：比如创建订单、计算金额等
        await Task.Delay(100);
        return new OrderResponse { OrderId = Guid.NewGuid(), Success = true };
    }
}

使用场景 #

• 当需要统一用IWorker<TRequest>类型处理所有Worker时，调用的是无返回的DoWork；
• 当明确需要获取结果时，用IWorker<TRequest, TResponse>类型调用带返回的方法，逻辑清晰无歧义。

方案二：拆分方法名（避免签名冲突） #

如果不想用new关键字，可以给带返回值的方法起不同的名称，比如ExecuteWork，这样接口继承关系更直观，也不会有方法重载的问题。

接口定义 #

public interface IWorker<TRequest>
{
    Task DoWork(TRequest request);
}

public interface IWorkerWithResult<TRequest, TResponse> : IWorker<TRequest>
{
    Task<TResponse> ExecuteWork(TRequest request);
}

实现类示例 #

public class PaymentWorker : IWorkerWithResult<PaymentRequest, PaymentResponse>
{
    public async Task DoWork(PaymentRequest request)
    {
        // 无返回场景下，调用带返回的方法并忽略结果
        await ExecuteWork(request);
    }

    public async Task<PaymentResponse> ExecuteWork(PaymentRequest request)
    {
        // 执行支付逻辑
        await Task.Delay(100);
        return new PaymentResponse { TransactionId = Guid.NewGuid(), Status = "Success" };
    }
}

使用场景 #

• 适合团队对方法命名有明确规范，不想用new关键字的场景；
• 方法名语义清晰，一看就知道哪个是带返回的操作。

方案三：基于Unit类型的通用接口设计（统一接口结构） #

如果希望所有Worker都遵循同一个核心接口结构，可以引入Unit类型（表示无返回值），将基接口作为泛型接口的特例，从根源上避免方法重载问题。

先定义Unit类型（或使用第三方库如MediatR的Unit） #

// 自定义Unit结构体，用于标记无返回值的操作
public struct Unit { }

接口定义 #

// 核心通用接口，所有Worker最终都实现此接口
public interface IWorker<TRequest, TResponse>
{
    Task<TResponse> DoWork(TRequest request);
}

// 无返回值的Worker接口，作为核心接口的特例
public interface IWorker<TRequest> : IWorker<TRequest, Unit> { }

实现类示例 #

// 无返回值的Worker
public class LogWorker : IWorker<LogRequest>
{
    public async Task<Unit> DoWork(LogRequest request)
    {
        // 执行日志记录逻辑
        await Task.Delay(50);
        Console.WriteLine($"记录日志：{request.Message}");
        return Unit.Value;
    }
}

// 带返回值的Worker
public class UserQueryWorker : IWorker<UserQueryRequest, UserInfoResponse>
{
    public async Task<UserInfoResponse> DoWork(UserQueryRequest request)
    {
        // 查询用户信息逻辑
        await Task.Delay(100);
        return new UserInfoResponse { Id = request.UserId, Name = "张三", Age = 30 };
    }
}

使用场景 #

• 适合希望统一所有Worker接口结构的场景，无返回和有返回的Worker遵循同一套模式；
• 配合依赖注入使用时，注册和解析逻辑更统一。

不推荐使用WorkResult属性的原因 #

你之前考虑的通过WorkResult属性获取结果的方案存在明显缺陷：

• 异步场景下，需要确保DoWork执行完成后才能读取WorkResult，容易出现竞态条件（比如还没执行完就读取结果）；
• 不符合异步编程的直观逻辑，方法返回结果是更自然的方式，代码可读性和可维护性更高。

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