Java方法提取优化：解决类内重复逻辑

在Java代码重构中，类内重复逻辑是影响代码质量和可维护性的常见问题。本文重点探讨如何运用方法提取技术，优化Java类中实体集合的数据转换过程，从而消除冗余代码。通过将重复的业务逻辑封装到相关实体类的新方法中，例如将角色列表转换为角色ID字符串列表的逻辑封装到`UserEntity`类的`getRoleIds()`方法中，可以显著提升代码的封装性、可读性和可维护性。本文通过具体案例，详细展示了如何识别重复代码模式，并将其高效地提取和封装，最终实现代码的精简和优化。该方法不仅减少了维护成本，还降低了潜在Bug的引入风险，是提升Java项目质量的重要实践。

本文探讨了如何在Java类中通过方法提取来消除重复代码，特别是在处理实体集合并进行数据转换的场景。核心策略是将重复的业务逻辑封装到相关实体类的新方法中，从而提高代码的封装性、可读性和可维护性，同时避免在多个方法中重复编写相同的数据处理逻辑。

在软件开发中，代码重复是一个常见的问题，它不仅增加了维护成本，还容易引入潜在的bug。当一个类中的多个方法执行相似的数据转换或集合处理逻辑时，这通常是进行重构的信号。本教程将通过一个具体的案例，演示如何利用方法提取（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 中获取角色列表（List），然后将其转换为一个包含角色ID字符串的列表（List）。

解决方案：方法提取与封装

解决这种重复代码的最佳实践是将该逻辑封装到一个独立的方法中。关键在于选择合适的方法归属。考虑到这段逻辑是关于 UserEntity 内部角色数据的转换，将其直接添加到 UserEntity 类中是更符合面向对象设计原则的做法。这不仅提高了 UserEntity 的封装性，也使得 UserEntity 自身能够更好地管理和提供其内部数据的不同表示形式。

1. 在 UserEntity 类中添加新方法

我们将提取的逻辑封装为 getRoleIds() 方法，并将其添加到 UserEntity 类中。

// UserEntity.java
public class UserEntity {
    private Integer id;
    private String email;
    private Date lastAccessDate;
    private List<RoleEntity> roles; // 假设RoleEntity包含getId()方法

    // ... 其他属性、构造函数、getter/setter ...

    /**
     * 获取用户所有角色的ID列表。
     * 将List<RoleEntity>转换为List<String> (角色ID)。
     * @return 包含角色ID字符串的列表。
     */
    public List<String> getRoleIds() {
        if (this.roles == null) {
            return Collections.emptyList(); // 或根据业务需求返回null
        }
        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检查或使用orElseThrow
    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;
}

注意事项与最佳实践

1. 封装性提升： 将数据转换逻辑放在 UserEntity 内部，使得 UserEntity 对其自身的数据表示拥有更强的控制权，外部类无需关心其内部角色列表的具体转换细节，只需调用一个高层次的方法即可获取所需结果。
2. 可读性与维护性： 新方法 getRoleIds() 具有清晰的名称，准确表达了其意图，使得调用方代码更加简洁易懂。如果未来角色ID的转换逻辑发生变化（例如，需要过滤特定类型的角色），只需修改 UserEntity 中的 getRoleIds() 方法，而无需改动所有调用它的地方。
3. 选择合适的封装位置： 在本例中，将方法添加到 UserEntity 是最合适的，因为它处理的是 UserEntity 的内部数据。如果重复的逻辑不紧密依赖于某个特定实体，而是一个通用的工具函数，则可以考虑创建一个独立的工具类或私有辅助方法。
4. 方法命名： 确保新方法的名称清晰、简洁，并准确反映其功能。例如，getRoleIds() 比 transformRolesToIds() 更为直接。
5. 空值处理： 在 getRoleIds() 方法中，对 this.roles 进行空值检查是一个良好的实践，以避免 NullPointerException。

总结

通过方法提取和恰当的封装，我们成功地消除了类内的重复代码，提高了系统的可维护性和可读性。这个案例强调了在重构过程中，不仅要识别重复代码，更要思考将这些重复逻辑封装到何处才能最大化地提升代码质量和符合面向对象设计原则。将与特定实体数据紧密相关的逻辑放置在该实体类内部，是实现高内聚、低耦合的有效手段。

本篇关于《Java方法提取优化：解决类内重复逻辑》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！