1. 问题背景与代码冗余分析
在软件开发过程中，代码冗余是一个常见且亟待解决的问题。当同一段逻辑出现在应用程序的不同方法中时，不仅增加了代码量，更重要的是降低了代码的可维护性、可读性，并增加了引入缺陷的风险。例如，当业务规则发生变化时，开发者需要修改所有包含该重复逻辑的地方，这极易遗漏或引入不一致性。
考虑以下Java代码示例，其中 map 方法用于将 UserEntity 转换为 UserDTO，而 updateUser 方法则处理用户更新逻辑：
原始代码片段：
// 方法一：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;
}在这两个方法中，提取用户角色ID列表的逻辑完全相同：
.getRoles().stream() .map(RoleEntity::getId) .map(String::valueOf) .collect(Collectors.toList())
这种重复不仅使得代码难以阅读，也使得未来对角色ID提取逻辑的任何修改都必须在两个地方进行，增加了出错的可能性。
立即学习“Java免费学习笔记（深入）”；
2. 解决方案：提取方法（Extract Method）
解决代码冗余最有效且最常用的策略之一是“提取方法”（Extract Method）重构技术。其核心思想是将一段重复的或具有独立逻辑的代码块封装成一个新的方法，然后在原有的位置调用这个新方法。
针对上述问题，最佳实践是将提取角色ID列表的逻辑封装到 UserEntity 类自身的一个新方法中。这样做有以下几个优点：
- 增强领域模型： UserEntity 作为领域对象，拥有获取其角色ID列表的能力是符合其职责的，这使得实体更加“智能”和自洽。
- 提高内聚性： 将与 UserEntity 相关的操作放在 UserEntity 类中，符合高内聚的设计原则。
- 简化调用： 调用方无需了解角色ID提取的具体实现细节，只需调用一个语义明确的方法即可。
2.1 改造 UserEntity 类
首先，在 UserEntity 类中添加一个名为 getRoleIds() 的新方法，用于封装提取角色ID的逻辑。
// 假设这是您的 UserEntity 类
public class UserEntity {
private Long id;
private String email;
private Date lastAccessDate;
private List roles; // 假设 RoleEntity 包含 getId() 方法
// ... 其他属性和方法
/**
* 获取用户所有角色的ID列表。
* @return 包含角色ID字符串的列表。
*/
public List getRoleIds() {
if (this.roles == null || this.roles.isEmpty()) {
return Collections.emptyList();
}
return this.roles.stream()
.map(RoleEntity::getId)
.map(String::valueOf)
.collect(Collectors.toList());
}
// Getter和Setter方法
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }
public String getEmail() { return email; }
public void setEmail(String email) { this.email = email; }
public Date getLastAccessDate() { return lastAccessDate; }
public void setLastAccessDate(Date lastAccessDate) { this.lastAccessDate = lastAccessDate; }
public List getRoles() { return roles; }
public void setRoles(List roles) { this.roles = roles; }
}
// 假设 RoleEntity 类
class RoleEntity {
private Long id;
private String name;
public RoleEntity(Long id, String name) {
this.id = id;
this.name = name;
}
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
} 2.2 重构调用方方法
一旦 UserEntity 拥有了 getRoleIds() 方法，我们就可以在原先存在重复逻辑的地方直接调用它，从而大大简化代码。
重构后的 map 方法：
protected UserDTO map(UserEntity entity) {
var result = new UserDTO();
// 调用 UserEntity 的新方法
var userRoles = entity.getRoleIds();
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()));
// 调用 UserEntity 的新方法
updatedUser.setRoles(optionalUser.get().getRoleIds());
updatedUser.setLastAccessDate(optionalUser.get().getLastAccessDate());
var entity = mapToUserEntity(updatedUser);
userRepository.save(entity);
return updatedUser;
}通过这种方式，原本冗长的流式操作被一个简洁、语义明确的方法调用所取代，代码变得更加清晰和易于维护。
3. 注意事项与最佳实践
在进行方法提取重构时，需要考虑以下几点以确保重构的质量和有效性：
- 方法命名： 新方法的名称应清晰、准确地表达其功能和意图。例如，getRoleIds() 明确表示获取角色ID列表。
- 方法可见性： 根据新方法的职责和调用范围，合理设置其可见性（public, protected, private）。如果它只在类内部使用，则应设为 private。在本例中，由于 getRoleIds() 可能被其他外部类（如服务层或DTO转换逻辑）调用，public 是合适的选择。
- 参数设计： 如果被提取的逻辑需要外部数据，应将这些数据作为参数传递给新方法。本例中，getRoleIds() 直接操作 UserEntity 自身的 roles 属性，无需额外参数。
- 无副作用原则： 尽量确保提取的方法是“纯函数”，即不修改其外部状态，只根据输入产生输出。如果必须有副作用，应明确文档说明。
- 测试覆盖： 在进行任何重构之前，确保有充分的单元测试覆盖。重构后，运行这些测试以验证功能的正确性未受影响。
- 粒度适中： 提取的方法不宜过大也不宜过小。过大可能包含多种职责，过小则可能引入过多方法调用开销且无明显收益。本例中提取的逻辑粒度适中，专注于一个单一的职责。
4. 总结
代码重构是软件开发中不可或缺的一部分，它有助于提升代码质量、降低维护成本。本文通过一个具体的Java代码冗余示例，演示了如何运用“提取方法”这一核心重构技术，将重复逻辑封装到领域实体类中。这种做法不仅有效地消除了代码冗余，还增强了领域模型的表达能力和代码的可读性。遵循这些最佳实践，开发者可以构建出更健壮、更易于管理和扩展的应用程序。
