在 Java 泛型设计中，当部分请求处理器（如 GetAll）无需输入参数时，不应强行用 Void 或通配符“模拟”空请求，而应通过职责分离定义专用接口（如 ParameterlessRequestHandler），提升类型安全性与可读性。
在 java 泛型设计中，当部分请求处理器（如 getall）无需输入参数时，不应强行用 `void` 或通配符“模拟”空请求，而应通过职责分离定义专用接口（如 `parameterlessrequesthandler`），提升类型安全性与可读性。
在构建分层架构（如 Web 层 → 领域层）时，采用“一个用例一个处理器”的轻量契约模式非常合理。你定义的泛型接口：
public interface RequestHandler<TResponse, TRequest> {
Response<TResponse> handle(TRequest request);
}已很好地表达了“有参请求→响应”的核心语义。但当遇到 GetAllUsers、ListActiveOrders 等无需任何请求数据的操作时，若强行复用该接口，常见反模式包括：
✅ 错误做法：RequestHandler
- , Void>
Void 是不可实例化的占位类型，调用方必须传入 null（如 handler.handle(null)），既违背直觉，又丧失编译期校验——null 可能被意外传入其他非空场景，埋下运行时隐患。❌ 更差做法：RequestHandler
- , ?> 或 RequestHandler
- , Object>
类型擦除后失去语义，且无法约束“无参数”这一明确意图。
✅ 推荐方案：定义清晰、正交的专用接口
立即学习“Java免费学习笔记（深入）”；
// 有参处理器：明确要求请求对象
public interface RequestHandler<TResponse, TRequest> {
Response<TResponse> handle(TRequest request);
}
// 无参处理器：零参数即零歧义
public interface ParameterlessRequestHandler<TResponse> {
Response<TResponse> handle();
}这样设计的优势在于：
- 类型安全：编译器强制区分 handle() 与 handle(request)，杜绝误用；
-
意图明确：接口名即契约——ParameterlessRequestHandler 比 RequestHandler
更直观、更自解释； - 扩展友好：未来可为无参场景添加专属行为（如自动审计日志、缓存策略），无需侵入泛型逻辑；
- 测试简洁：单元测试无需构造/传递 null，直接调用 handle() 即可验证。
⚠️ 注意事项：避免在泛型中滥用 Void。它本是为反射和函数式 API（如 Callable
）中“返回 void 的回调”而设，并非语义化建模工具。主动设计接口时，应优先选择显式、具名、无歧义的类型契约。
总结：泛型不是万能胶——当业务语义出现本质差异（有参 vs 无参），就该用接口拆分来表达这种差异。这不仅是 Java 类型系统的最佳实践，更是领域驱动设计（DDD）中“限界上下文”与“明确契约”思想的落地体现。
