在 Java 泛型设计中，面对“有参请求”与“无参请求”（如 GetAll）共存的场景，不应强行用 Void 或泛型约束模糊语义，而应通过职责分离——为无参场景定义独立接口，提升类型安全性与代码可读性。
在 java 泛型设计中，面对“有参请求”与“无参请求”（如 getall）共存的场景，不应强行用 `void` 或泛型约束模糊语义，而应通过职责分离——为无参请求场景定义独立接口，提升类型安全性与代码可读性。
当你构建分层架构（如 Web 层 → 领域层）并采用「一个用例一个处理器」的设计理念时，RequestHandler
// ❌ 不推荐：语义混淆，易引发误用
public class GetAllUsersHandler implements RequestHandler<List<User>, Void> {
@Override
public Response<List<User>> Handle(Void request) {
// 必须传入 null —— 但 Void 无法实例化，实际只能传 null，失去类型保护
return Response.success(userRepository.findAll());
}
}Void 是 Java 中仅用于表示「无返回值」的占位符类（其构造函数私有），不可实例化。虽然编译器允许 TRequest extends Void 的泛型声明，但调用方必须传入 null，这既破坏了空安全契约，又让 API 意图变得隐晦：Handle(null) 看似异常，实则被设计为合法行为——这种反直觉设计极易埋下运行时隐患（如 NPE、逻辑分支遗漏）。
✅ 正确做法是遵循接口隔离原则（ISP），为无参场景显式定义专用接口：
// ✅ 推荐：语义明确、类型安全、零歧义
public interface RequestHandler<TResponse, TRequest> {
Response<TResponse> handle(TRequest request);
}
public interface ParameterlessRequestHandler<TResponse> {
Response<TResponse> handle(); // 无参数，无需传 null
}
// 具体实现示例
public class GetAllUsersHandler implements ParameterlessRequestHandler<List<User>> {
@Override
public Response<List<User>> handle() {
return Response.success(userRepository.findAll());
}
}
public class CreateUserHandler implements RequestHandler<User, CreateUserRequest> {
@Override
public Response<User> handle(CreateUserRequest request) {
return Response.success(userService.create(request));
}
}这种设计带来三重优势：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 类型安全：编译期杜绝 null 参数误传；
- 意图清晰：开发者一眼识别该处理器是否依赖输入；
- 扩展友好：未来可为无参处理器添加统一拦截逻辑（如审计日志、权限校验），无需条件判断 request == null。
⚠️ 补充提醒：避免在泛型中滥用 ? extends Object 或 TRequest extends java.lang.Void 等技巧试图“兼容”空参数——它们牺牲了可读性与健壮性，违背了泛型设计初衷。真正的灵活性源于良好的抽象，而非语法上的取巧。
总结：当业务语义存在本质差异（有参 vs 无参），就该用不同的接口表达它。这不是冗余，而是对领域逻辑的尊重。
