应遵循单一职责原则，将承担过多职责的类按功能拆分为多个专注特定任务的小类，如将UserManager拆分为UserRegistrationService、UserRepository和EmailService，通过依赖注入实现松耦合，使每个类只因一个原因变化，提升可维护性、可测试性和复用性。
在Java中，让对象承担正确的职责，关键在于遵循单一职责原则（Single Responsibility Principle, SRP）。SRP 指的是一个类应该只有一个引起它变化的原因，换句话说，一个类只负责一项核心任务。当类承担了过多职责时，会导致代码难以维护、测试和扩展。通过合理拆分类，可以让每个对象专注于自己的职责。
识别职责重叠的信号
以下是一些常见的“坏味道”，表明类可能违反了SRP：
- 类中方法数量过多：尤其是方法之间处理完全不同的业务逻辑。
- 类被多个模块频繁修改：比如既因用户界面调整而改，又因数据存储逻辑变更而改。
- 方法间共用字段少或无关联：部分方法只操作某些字段，其他方法操作另一些字段，彼此独立。
- 单元测试覆盖困难：测试一种行为需要模拟与之无关的组件。
按功能拆分职责
将一个大类按实际功能划分为多个小类，每个类专注处理一个方面。例如，有一个UserManager类同时处理用户注册、数据持久化和邮件通知：
class UserManager {void register(String email, String password) {
// 验证输入
// 保存到数据库
// 发送欢迎邮件
}
}
这明显承担了三种职责。应将其拆分为：
立即学习“Java免费学习笔记（深入）”；
- UserRegistrationService：处理注册流程协调。
- UserRepository：负责用户数据的存储与读取。
- EmailService：发送邮件通知。
拆分后，UserRegistrationService只需调用其他组件完成各自任务，自身不实现细节。
使用依赖注入组合职责
拆分后，通过构造函数注入依赖，保持松耦合：
class UserRegistrationService {private UserRepository userRepository;
private EmailService emailService;
public UserRegistrationService(UserRepository userRepository, EmailService emailService) {
this.userRepository = userRepository;
this.emailService = emailService;
}
public void register(String email, String password) {
User user = new User(email, password);
userRepository.save(user);
emailService.sendWelcome(email);
}
}
这样，每个类各司其职，修改数据库逻辑不影响邮件发送，反之亦然。
关注点分离提升可维护性
拆分后的类更易于：
- 单独测试：可以为UserRepository写数据层测试，为EmailService模拟邮件客户端。
- 复用：其他服务也可以使用EmailService发送不同类型的邮件。
- 并行开发：不同开发者可以独立修改不同类，减少冲突。
基本上就这些。只要持续审视类的行为是否聚焦，及时拆解混合职责，就能让对象真正承担起“正确”的责任。
