本文介绍如何将多个 rest 接口（如 get、delete）中重复的资源校验逻辑（如双 id 查找、归属关系验证）抽取为私有辅助方法，提升代码复用性与可维护性，并给出安全、清晰的实现范式。
在构建 RESTful 服务时，不同 HTTP 方法（如 GET、DELETE、PUT）常需执行相同的前置校验：根据 projectManagerId 和 questionnaireId 分别加载实体，并验证问卷是否归属该项目经理。若每处都重复编写查找 + 校验逻辑，不仅违反 DRY（Don’t Repeat Yourself）原则，还会增加维护成本和出错风险。
理想的解法是将共用逻辑封装为职责单一的私有方法。注意：该辅助方法不应直接返回 DTO 或 void，而应返回核心业务实体（Questionnaire），由调用方按需后续处理（如转换、删除、更新）。这样既保证了复用性，又保持了各接口行为的语义清晰。
以下是重构后的推荐实现：
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
@Override
public QuestionnaireDTO methodOne(long projectManagerId, long questionnaireId) {
Questionnaire questionnaire = findById(projectManagerId, questionnaireId);
return mapToDto(questionnaire); // GET：查后转 DTO
}
@Override
public QuestionnaireDTO methodTwo(long projectManagerId, long questionnaireId) {
Questionnaire questionnaire = findById(projectManagerId, questionnaireId);
questionnaireRepository.delete(questionnaire); // DELETE：查后删实体
return mapToDto(questionnaire); // 可选：返回被删资源的快照（符合 REST 最佳实践）
}
/**
* 公共校验方法：根据 projectManagerId 和 questionnaireId 加载并验证归属关系
* @return 已通过权限校验的 Questionnaire 实体
* @throws ResourceNotFoundException 当任一 ID 未找到时
* @throws QuestionnaireApiException 当问卷不属于指定项目经理时
*/
private Questionnaire findById(long projectManagerId, long questionnaireId) {
ProjectManager projectManager = projectManagerRepository.findById(projectManagerId)
.orElseThrow(() -> new ResourceNotFoundException("ProjectManager", "id", projectManagerId));
Questionnaire questionnaire = questionnaireRepository.findById(questionnaireId)
.orElseThrow(() -> new ResourceNotFoundException("Questionnaire", "id", questionnaireId));
if (!questionnaire.getProjectManager().getId().equals(projectManager.getId())) {
throw new QuestionnaireApiException(HttpStatus.BAD_REQUEST,
"Questionnaire not belonging to Project Manager");
}
return questionnaire;
}✅ 关键设计要点说明：
- 返回实体而非 DTO 或 void：确保调用方灵活决定后续操作（映射、删除、更新等），避免辅助方法承担过多职责；
- 异常语义明确：复用原异常类型（ResourceNotFoundException、QuestionnaireApiException），保障全局异常处理器一致性；
- 方法命名精准：findById 直观表达其核心能力（基于 ID 查找+校验），比泛称 validateAndLoad 更具可读性；
- 无副作用：辅助方法仅做查询与校验，不修改状态，符合函数式设计思想，便于单元测试。
⚠️ 注意事项：
- 若未来需支持其他资源（如 Survey、Report）的同类校验，可进一步泛型化或抽象为模板方法，但当前场景下简单私有方法已足够简洁高效；
- 切勿在辅助方法中调用 repository.delete() 或 mapToDto() —— 这会耦合具体业务意图，破坏复用前提；
- 建议为 findById 添加 JavaDoc，明确契约（输入、输出、异常），提升团队协作效率。
通过这一重构，不仅消除了 IntelliJ 的“duplicated code fragment”警告，更让业务逻辑主干更聚焦、校验逻辑更集中、后续扩展（如增加审计日志、缓存拦截）也有了统一入口。
