本文介绍如何通过提取校验逻辑、引入函数式断言和合理分层，重构冗长的服务方法输入校验，使代码更清晰、可测、可复用，并避免重复校验与职责混杂。
本文介绍如何通过提取校验逻辑、引入函数式断言和合理分层，重构冗长的服务方法输入校验，使代码更清晰、可测、可复用，并避免重复校验与职责混杂。
在微服务或分层架构中，服务方法常承担业务逻辑与前置校验双重职责，导致方法臃肿、校验散落、复用困难——正如原始示例中，exampleMethod 同时处理空值检查、远程调用分支、创建/更新流程及多条件校验，违反单一职责原则，也增加了单元测试复杂度。
推荐重构路径：职责分离 + 策略化校验 + 声明式表达
首先，将校验逻辑彻底抽离为独立、可组合的私有方法（如 validateUser），明确其契约：校验失败即抛出统一异常，成功则静默返回。这不仅提升可读性，还便于在多个方法间复用：
private void validateUser(UserDto user) {
if (user == null) {
throw new CustomHandledException("User must not be null");
}
if (user.getId() == null) {
throw new CustomHandledException("User ID is required");
}
if (user.getGivenName() == null || user.getGivenName().trim().isEmpty()) {
throw new CustomHandledException("Given name is required");
}
if (user.getEmail() == null || !RequestValidator.validateEmail(user.getEmail())) {
throw new CustomHandledException("Valid email is required");
}
if (user.getLocale() == null) {
throw new CustomHandledException("Locale is required");
}
if (!user.getGivenName().startsWith("text")) {
throw new CustomHandledException("Given name must start with 'text'");
}
}
✅ 优势：语义清晰、错误信息精准、无布尔返回干扰控制流；相比
Predicate链式调用，显式if更易调试、IDE 友好，且避免NullPointerException隐患（如user.getGivenName().startsWith(...)在getGivenName()为null时会崩溃）。
其次，注意校验时机的一致性。原始代码中，user.getGivenName() 和 user.getEmail() 仅在 getUserResponse == null 分支才校验，但实际它们是创建用户的必要字段，理应前置校验——否则可能因远程调用成功而跳过校验，导致数据不一致。重构后，validateUser() 在方法入口处统一执行，确保所有业务路径均受控。
最后，可进一步演进至更高级模式：
-
AOP 方案：对带
@Validated注解的方法自动织入校验切面，适合全局通用规则（如非空、长度）； -
领域验证器（Domain Validator）：定义
UserValidator类封装全部用户规则，支持组合与上下文感知（如“创建场景” vs “更新场景”）； -
Builder + Validation API：结合 Jakarta Bean Validation（
@NotNull,@Email）与Validator接口，实现声明式 + 运行时校验。
⚠️ 注意事项：
- 避免在
validateXxx()中调用外部服务或数据库——校验应是纯内存操作，保障性能与确定性； - 错误码与消息需面向运维友好（如区分
VALIDATION_USER_ID_MISSING），而非硬编码"example"； - 若校验规则随业务频繁变更，建议将部分规则外置为配置（如正则、长度阈值），提升灵活性。
总结：清洁的服务方法 = 明确入口契约 + 纯校验前置 + 专注核心路径。一次校验、处处可靠；一处修改、全局生效——这才是可演进、易协作的高质量服务代码基石。
