本文介绍如何通过提取验证逻辑、引入函数式断言和合理分层，重构冗长的服务方法输入校验代码，使其更清晰、可复用、易测试且符合单一职责原则。
本文介绍如何通过提取验证逻辑、引入函数式断言和合理分层，重构冗长的服务方法输入校验代码，使其更清晰、可复用、易测试且符合单一职责原则。
在典型的 Spring 或 Java 服务层开发中，业务方法常需对入参进行多层级校验（如非空、格式、业务约束等）。若将所有校验逻辑直接堆砌在方法体内（如原始代码所示），会导致方法臃肿、职责混杂、重复校验难以复用，且违反“一个方法只做一件事”的 Clean Code 原则。
核心重构思路有三：
- ✅ 职责分离：将校验逻辑从主业务流中剥离，封装为独立、可组合的验证单元；
- ✅ 语义化抽象：用
Predicate或专用 Validator 类表达校验规则，提升可读性与可测试性； - ✅ 提前失败（Fail Fast）：在进入核心业务前完成全部必要校验，避免无效调用远程服务或执行副作用操作。
以下是一个优化后的实践示例（基于原始逻辑演进）：
public void exampleMethod(final UserDto user, String sthElse) {
// Step 1: 快速失败 —— 校验顶层参数
validateMandatoryArgs(user, sthElse);
// Step 2: 查询现有用户（可能触发远程调用）
GetUserResponseDto response = client.getUserById(user.getId(), country);
// Step 3: 分支处理 —— 创建 or 更新
if (response == null) {
// 创建路径：此时需确保 user 具备创建所需字段（email、givenName、locale 等）
validateUserForCreation(user);
client.createUser(UserMapper.toCreateBody(user));
} else if (!user.getLocale().equals(response.getUser().getProfile().getLocale())) {
// 更新路径：同样需校验更新前提（例如 locale 变更需满足约束）
validateUserForUpdate(user);
client.updateUser(user);
}
// 否则：locale 未变更，无需操作 → 自然返回
}
// 统一入口：校验方法级必传参数（非业务域，属协议契约）
private void validateMandatoryArgs(UserDto user, String sthElse) {
if (user == null || user.getId() == null) {
throw new CustomHandledException("User and its ID must not be null");
}
if (sthElse == null) {
throw new CustomHandledException("sthElse is required");
}
}
// 业务域校验：聚焦 UserDto 的创建合规性
private void validateUserForCreation(UserDto user) {
List<validationrule>> rules = List.of(
notNull("id", UserDto::getId),
notNull("givenName", UserDto::getGivenName),
notNull("email", UserDto::getEmail),
notNull("locale", UserDto::getLocale),
validEmail(UserDto::getEmail),
startsWith("givenName", "text")
);
validateAll(user, rules);
}
// 复用同一套校验机制，按场景定制规则集（如更新时可放宽某些字段）
private void validateUserForUpdate(UserDto user) {
validateUserForCreation(user); // 默认继承创建规则
// 可追加更新专属规则，例如：if (user.isLocked()) throw ...
}</validationrule>
辅助工具类（提升复用性与类型安全）：
@FunctionalInterface
interface ValidationRule<t> {
void validate(T target) throws CustomHandledException;
}
static <t> ValidationRule<t> notNull(String field, Function<t object> extractor) {
return target -> {
if (extractor.apply(target) == null) {
throw new CustomHandledException("Field '" + field + "' must not be null");
}
};
}
static <t> ValidationRule<t> validEmail(Function<t string> emailExtractor) {
return target -> {
String email = emailExtractor.apply(target);
if (!email.matches("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$")) {
throw new CustomHandledException("Invalid email format");
}
};
}
static <t> void validateAll(T target, List<validationrule>> rules) {
rules.forEach(rule -> rule.validate(target));
}</validationrule></t></t></t></t></t></t></t></t>
✅ 优势总结：
-
可读性提升：
validateUserForCreation()明确表达了业务意图，而非一堆if (x == null)； -
可维护性强：新增/修改校验规则只需增删
ValidationRule，不影响主流程； -
可测试友好：每个
ValidationRule可单独单元测试，主方法只需 mock client 验证分支逻辑； -
扩展灵活：支持按场景组合规则（创建/更新/删除）、支持国际化错误消息、可无缝接入 Bean Validation（如
@Valid+@Constraint）或 AOP 拦截器（如@ValidateOnCall）。
⚠️ 注意事项：
- 避免在验证方法中引入副作用（如日志、缓存、远程调用）；
- 对性能敏感路径（如高频接口），应权衡
Predicate链式调用与早期return的开销，必要时用传统if提前退出； - 若项目已采用 Jakarta Bean Validation（
@NotNull,@Email），建议统一使用@Valid+MethodValidationPostProcessor实现声明式校验，进一步解耦。
最终目标不是“写得最少”，而是“改得最稳”——当业务规则变化时，开发者能精准定位、快速修改、信心十足地交付。
