Java代码重构：通过方法提取优化类内重复逻辑

本文讨论了如何通过Java类别中的方法提取来消除重复代码特别是在处理实体集合和数据转换的场景中。核心策略是将重复的业务逻辑包装到相关实体类别的新方法中以提高代码的包装、可读性和可维护性避免在多种方法中重复编写相同的数据处理逻辑。在软件开发中代码重复是一个常见的问题它不仅增加了维护成本而且很容易引入潜在的错误。当一个类中的多种方法执行类似的数据转换或集合处理逻辑时这通常是重构的信号。本教程将演示如何通过特定的案例提取Method Extraction该重构技术有效地解决了类内代码重复的问题。识别重复代码模式考虑到以下两种Java方法它们负责映射用户实体到DTO更新用户资源原始方法一map 方法protected UserDTO map(UserEntity entity) { var result new UserDTO(); // 重复代码片段开始 var userRoles entity.getRoles().stream() .map(RoleEntity::getId) .map(String::valueOf) .collect(Collectors.toList()); // 重复代码片段结束 result.setId(entity.getId().toString()); result.setLastAccessDate(entity.getLastAccessDate()); result.setRoles(userRoles); if (entity.getEmail() ! null) { var email new UserDTO.Email(entity.getEmail(), EMAIL_TYPE); result.setEmails(List.of(email)); } return result; }原始方法二updateUser 方法public UserResource updateUser(String id, UserResource updatedUser) { var optionalUser userRepository.findById(Integer.valueOf(updatedUser.getUserName())); // 重复代码片段开始 updatedUser.setRoles(optionalUser.get().getRoles() .stream() .map(RoleEntity::getId) .map(String::valueOf) .collect(Collectors.toList())); // 重复代码片段结束 updatedUser.setLastAccessDate(optionalUser.get().getLastAccessDate()); var entity mapToUserEntity(updatedUser); userRepository.save(entity); return updatedUser; }在这两种方法中以下代码片段完全重复.getRoles().stream() .map(RoleEntity::getId) .map(String::valueOf) .collect(Collectors.toList());这个代码的作用是从 UserEntity 获取角色列表ListRoleEntity然后将其转换为包含角色ID字符串的列表ListString。解决方案方法提取和包装解决这个重复代码的最佳实践是将逻辑包装成一种独立的方法。关键是选择合适的方法。考虑到这个逻辑是关于的 UserEntity 将内部角色数据的转换直接添加到 UserEntity 类别更符合面向对象的设计原则。这不仅改进了 UserEntity 包装也使得 UserEntity 能够更好地管理和提供其内部数据的不同表达形式。1. 在 UserEntity 在类中添加新的方法我们将提取的逻辑封装为 getRoleIds() 并添加到方法中 UserEntity 类中。// UserEntity.java public class UserEntity { private Integer id; private String email; private Date lastAccessDate; private ListRoleEntity roles; // 假设Roleentity包含getid()方法 // ... 其它属性构造函数getter/setter ... /** * 获取用户所有角色的ID列表。 * 将ListRoleEntity转换为ListString (角色ID)。 * return 列表包含角色ID字符串。 */ public ListString getRoleIds() { if (this.roles null) { return Collections.emptyList(); // 或者根据业务需要返回nullll } return this.roles.stream() .map(RoleEntity::getId) .map(String::valueOf) .collect(Collectors.toList()); } } // RoleEntity.java (示例) public class RoleEntity { private Integer id; private String name; // ... 其它属性构造函数getter/setter ... public Integer getId() { return id; } // ... }2. 更新调用方法如今原始方法中的重复代码可以简单地替换为对。 entity.getRoleIds() 的调用。优化后的 map 方法protected UserDTO map(UserEntity entity) { var result new UserDTO(); var userRoles entity.getRoleIds(); // Userentity中的新方法直接调用 result.setId(entity.getId().toString()); result.setLastAccessDate(entity.getLastAccessDate()); result.setRoles(userRoles); if (entity.getEmail() ! null) { var email new UserDTO.Email(entity.getEmail(), EMAIL_TYPE); result.setEmails(List.of(email)); } return result; }优化后的 updateUser 方法public UserResource updateUser(String id, UserResource updatedUser) { var optionalUser userRepository.findById(Integer.valueOf(updatedUser.getUserName())); // 确保optionaluser不空在实际生产中应进行null检查或使用orelsethroww if (optionalUser.isPresent()) { updatedUser.setRoles(optionalUser.get().getRoleIds()); // Userentity中的新方法直接调用 updatedUser.setLastAccessDate(optionalUser.get().getLastAccessDate()); } else { // 处理用户不存在的情况例如抛出异常 throw new UserNotFoundException(User with username updatedUser.getUserName() not found.); } var entity mapToUserEntity(updatedUser); userRepository.save(entity); return updatedUser; }注意事项和最佳实践包装提升 放置数据转换逻辑 UserEntity 内部使得 UserEntity 他们对自己的数据有更强的控制权。外部类不需要关注其内部角色列表的具体转换细节。他们只需要调用高级方法就可以获得所需的结果。可读性和维护性 新方法 getRoleIds() 名称清晰意图表达准确使调用方代码更容易理解。如果角色ID的转换逻辑在未来发生变化例如需要过滤特定类型的角色只需修改即可 UserEntity 中的 getRoleIds() 方法不需要改变所有调用它的地方。选择合适的封装位置 在这种情况下添加方法 UserEntity 因为它处理的是最合适的所以处理的是最合适的。 UserEntity 内部数据。如果重复的逻辑不是一个特定的实体而是一个通用的工具函数则可以考虑创建一个独立的工具或私人辅助方法。方法命名 确保新方法的名称清晰、简洁并准确反映其功能。例如getRoleIds() 比 transformRolesToIds() 更为直接。空值处理 在 getRoleIds() 方法中对 this.roles 进行空值检查是避免空值检查的良好实践 NullPointerException。总结通过方法提取和适当的包装我们成功地消除了类中的重复代码提高了系统的可维护性和可读性。本案例强调在重建过程中我们不仅要识别重复代码还要考虑在哪里包装这些重复逻辑以最大限度地提高代码质量并遵循面向对象的设计原则。将与特定物理数据密切相关的逻辑放置在物理类中是实现高内聚和低耦合的有效手段。