在软件开发过程中，代码冗余是一个常见的问题，尤其是在处理相似业务逻辑或异常场景时。当多个功能模块需要执行几乎相同的操作，仅在少数参数或结果上有所区别时，开发者可能会倾向于复制粘贴现有代码，然后进行少量修改。这种做法虽然在短期内看似效率高，但长期来看会导致代码库膨胀、维护困难，并增加引入bug的风险。
以Spring Boot的全局异常处理为例，开发者通常会使用@ExceptionHandler注解来捕获特定类型的异常，并返回统一的错误响应。然而，当需要处理多种异常，且每种异常的响应结构相似（例如，都返回ErrorDto），但状态码或特定字段值不同时，就会出现大量重复的代码。
考虑以下三个异常处理器示例：
@ExceptionHandler(value = {ProhibitedScimTypeException.class})
public ResponseEntity<ErrorDto> policyConflict(final ProhibitedScimTypeException exception) {
final var errorDto = new ErrorDto();
errorDto.setDetail(exception.getMessage());
errorDto.setStatus(BAD_REQUEST.toString());
errorDto.setScimType("prohibited");
return new ResponseEntity<>(errorDto, HttpStatus.BAD_REQUEST);
}
@ExceptionHandler(value = {UserAlreadyExistsException.class})
public ResponseEntity<ErrorDto> userNameExistsConflict(final UserAlreadyExistsException exception) {
final var errorDto = new ErrorDto();
errorDto.setDetail(exception.getMessage());
errorDto.setStatus(CONFLICT.toString());
errorDto.setScimType("uniqueness");
return new ResponseEntity<>(errorDto, HttpStatus.CONFLICT);
}
@ExceptionHandler(value = {UserNotFoundException.class})
public ResponseEntity<ErrorDto> userNameNotFoundConflict(final UserNotFoundException exception) {
final var errorDto = new ErrorDto();
errorDto.setDetail(exception.getMessage());
errorDto.setStatus(NOT_FOUND.toString());
errorDto.setScimType("prohibited");
return new ResponseEntity<>(errorDto, HttpStatus.NOT_FOUND);
} 从上述代码中可以看出，尽管处理的异常类型和返回的HTTP状态码、scimType字段有所不同，但构建ErrorDto对象、设置detail、status、scimType以及创建ResponseEntity的逻辑是高度重复的。这种重复性使得代码难以阅读，且一旦ErrorDto的构建逻辑发生变化，就需要修改所有相关的异常处理器。
核心策略：提取公共方法解决代码冗余的有效策略是遵循“Don't Repeat Yourself (DRY)”原则，将重复的逻辑提取到一个独立的、可复用的方法中。对于上述异常处理器的场景，我们可以识别出以下公共部分：
- 创建ErrorDto实例。
- 设置ErrorDto的detail字段为异常消息。
- 设置ErrorDto的status字段为HTTP状态码的字符串表示。
- 设置ErrorDto的scimType字段。
- 构建并返回ResponseEntity<ErrorDto>。
而变化的部分在于：
- HTTP状态码（例如BAD_REQUEST、CONFLICT、NOT_FOUND）。
- scimType字段的值（例如"prohibited"、"uniqueness"）。
- 捕获的异常对象（虽然类型不同，但都可以作为Throwable处理以获取消息）。
基于此分析，我们可以创建一个私有辅助方法，将这些可变部分作为参数传入，从而封装重复的逻辑。
示例：创建通用异常响应方法下面是提取出的通用异常响应方法createErrorResponseEntity（或类似名称，此处使用conflict作为示例）：
private ResponseEntity<ErrorDto> conflict(final Throwable exception, HttpStatus status, String scimType) {
final var errorDto = new ErrorDto();
errorDto.setDetail(exception.getMessage()); // 从异常中获取详细信息
errorDto.setStatus(status.toString()); // 设置HTTP状态码的字符串表示
errorDto.setScimType(scimType); // 设置特定的scimType
return new ResponseEntity<>(errorDto, status); // 返回ResponseEntity
} 这个conflict方法接收三个参数：
- exception (类型为Throwable): 允许传入任何异常类型，因为我们只需要其getMessage()方法。
- status (类型为HttpStatus): 用于指定HTTP响应的状态码，同时也会设置到ErrorDto的status字段。
- scimType (类型为String): 用于设置ErrorDto中特有的scimType字段值。
通过这个辅助方法，所有重复的ErrorDto构建和ResponseEntity返回逻辑都被集中管理。
示例：重构异常处理器有了conflict辅助方法后，原始的异常处理器可以被大幅简化，变得更加简洁和可读：
@ExceptionHandler(value = {ProhibitedScimTypeException.class})
public ResponseEntity<ErrorDto> policyConflict(final ProhibitedScimTypeException exception) {
return conflict(exception, HttpStatus.BAD_REQUEST, "prohibited");
}
@ExceptionHandler(value = {UserAlreadyExistsException.class})
public ResponseEntity<ErrorDto> userNameExistsConflict(final UserAlreadyExistsException exception) {
return conflict(exception, HttpStatus.CONFLICT, "uniqueness");
}
@ExceptionHandler(value = {UserNotFoundException.class})
public ResponseEntity<ErrorDto> userNameNotFoundConflict(final UserNotFoundException exception) {
return conflict(exception, HttpStatus.NOT_FOUND, "prohibited");
} 重构后的代码清晰地展示了每个异常处理器仅关注其特有的参数（HTTP状态码和scimType），而将通用的响应构建细节委托给了conflict方法。这显著提升了代码的简洁性和可维护性。
实践考量与最佳实践在进行此类代码重构时，需要考虑以下几点以确保代码质量和可维护性：
- DRY原则的实践： 这是重构的核心目标。通过提取公共方法，我们避免了代码的重复，使得修改一处逻辑即可影响所有相关部分，极大地降低了维护成本和出错率。
- 参数化设计： 仔细识别代码中哪些是常量，哪些是变量。将变量抽象为方法的参数，是实现代码复用的关键。参数的命名应清晰，准确反映其用途。
- 方法可见性： 辅助方法通常应声明为private。这表明该方法仅供当前类内部使用，不应暴露给外部，从而维护了类的封装性。如果该辅助方法可能被多个类使用，可以考虑将其提升为公共工具类中的静态方法，但这需要更谨慎的设计。
-
提升代码质量：
- 可读性： 重构后的代码意图更明确，一眼就能看出每个异常处理器在做什么。
- 可测试性： 独立的辅助方法更容易进行单元测试，因为它封装了特定的逻辑，可以独立于整个异常处理流程进行验证。
- 可维护性： 当需要修改ErrorDto的构建方式或响应结构时，只需修改conflict方法即可，无需逐个修改每个异常处理器。
- 通用性： 这种提取公共方法的模式并非仅限于异常处理。在任何存在相似逻辑块的场景中，例如数据转换、日志记录、通用验证等，都可以应用此模式来优化代码结构。
通过将重复的业务逻辑或通用代码块提取到独立的辅助方法中，我们可以有效地消除代码冗余，提升代码的可读性、可维护性和可测试性。在Spring Boot的异常处理场景中，这种重构策略尤为有效，它使得异常处理器更加专注于其核心职责，而将响应构建的细节抽象化。遵循DRY原则，积极寻找并消除代码中的重复模式，是编写高质量、可扩展软件的重要实践。
以上就是Spring Boot异常处理：重构重复代码以提升可维护性的详细内容，更多请关注知识资源分享宝库其它相关文章！
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。