Java 中如何优雅处理无请求参数的请求处理器：推荐使用专用接口而非泛型约束

在 Ja va 泛型设计里，一提到同时支持“有参请求”和“无参请求”（比如 GetAll 这种场景），很多人第一反应是：能不能用 Void 来凑合？或者干脆用泛型约束强行兼容？事实上，这条路往往走不通——更好的做法是职责分离，为无参场景定义独立的接口，这样类型安全性和代码可读性都能上一个台阶。

在 Ja va 泛型设计中，面对“有参请求”与“无参请求”（如 GetAll）共存的场景，不应强行用 Void 或泛型约束模糊语义，而应通过职责分离——为无参场景定义独立接口，提升类型安全性与代码可读性。

当你搭建分层架构（比如 Web 层→领域层），并采用“一个用例一个处理器”这种设计理念时，RequestHandler 是一个很自然的起点。但实战中很快就会发现：并非所有用例都需要输入参数——GetAllUsers、PingHealthCheck、GenerateReport 这些操作天然就没有请求体。这时候，如果硬要复用同一个泛型接口，常见的误区就是把 TRequest 设为 Void：

// ❌ 不推荐：语义混淆，易引发误用
public class GetAllUsersHandler implements RequestHandler, Void> {
    @Override
    public Response> Handle(Void request) {
        // 必须传入 null —— 但 Void 无法实例化，实际只能传 null，失去类型保护
        return Response.success(userRepository.findAll());
    }
}

这里得说明一下：Void 在 Ja va 里是个只用来表示“无返回值”的占位符类（构造函数是私有的），根本没法实例化。虽然编译器允许 TRequest extends Void 这种泛型声明，但调用方只能传 null——这既破坏了空安全契约，又让 API 的意图变得极其隐晦。Handle(null) 看起来像是个异常写法，结果居然是合法行为……这种反直觉的设计，很容易埋下运行时隐患（比如 NPE、逻辑分支遗漏）。

那正确做法是什么？其实很简单——遵循接口隔离原则（ISP），为无参场景显式定义一个专用接口：

// ✅ 推荐：语义明确、类型安全、零歧义
public interface RequestHandler {
    Response handle(TRequest request);
}

public interface ParameterlessRequestHandler {
    Response handle(); // 无参数，无需传 null
}

// 具体实现示例
public class GetAllUsersHandler implements ParameterlessRequestHandler> {
    @Override
    public Response> handle() {
        return Response.success(userRepository.findAll());
    }
}

public class CreateUserHandler implements RequestHandler {
    @Override
    public Response handle(CreateUserRequest request) {
        return Response.success(userService.create(request));
    }
}

这种设计带来的好处是明显的：

• 类型安全：编译期就能杜绝 null 参数误传；
• 意图清晰：开发者一眼就能看出这个处理器到底需不需要输入；
• 扩展友好：将来想给无参处理器统一加拦截逻辑（比如审计日志、权限校验），直接对 ParameterlessRequestHandler 下手就行，不用到处 if (request == null)。

⚠️ 最后提醒一句：别在泛型里滥用 ? extends Object 或者 TRequest extends ja va.lang.Void 这类技巧，试图“兼容”空参数——它们牺牲了可读性与健壮性，完全违背了泛型的设计初衷。真正的灵活性来自良好的抽象，而不是语法上的取巧。

总结一下：当业务语义本身存在本质差异（有参 vs 无参），就应该用不同的接口把它表达出来。这不是冗余，而是对领域逻辑的尊重。