一个类应只承担一项职责，通过识别方法过多、字段分散、修改原因多样等迹象，可将臃肿类拆分为多个单一职责的类，如提取服务类、分离数据访问与业务逻辑、使用组合替代继承，并通过细粒度接口明确边界，最终提升代码可维护性与系统灵活性。
单一职责原则（SRP）是面向对象设计的重要基础，它要求一个类只负责一项职责。当Java类变得臃肿、承担过多功能时，代码会变得难以维护、测试和扩展。要避免这种情况，关键在于识别职责边界并进行合理拆分。
识别类中的多重职责
一个类如果包含以下特征，很可能违反了单一职责：
- 方法数量过多：超过20个方法的类通常在做太多事。
- 字段用途分散：成员变量服务于不同业务逻辑，比如既有用户认证信息又有订单统计字段。
- 修改原因多样：因为登录逻辑变更要改它，因为报表导出也要改它，说明它承担了多个责任。
- 难以命名：类名含“Manager”、“Utils”、“Service”等泛化词汇，往往掩盖了实际职责不清的问题。
通过分析调用关系和业务场景，可以将大类中相关的方法与字段归为一组，每组对应一个明确的职责。
按职责拆分类的常见方式
一旦识别出多个职责，就可以采用以下结构化方式进行拆分：
立即学习“Java免费学习笔记（深入）”；
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 提取服务类：将业务处理逻辑从实体类或主服务中剥离。例如，User类不应包含发送邮件的逻辑，应交给EmailNotificationService处理。
- 使用组合替代继承：不要为了复用功能让类继承庞大父类。而是将功能封装成独立组件，通过成员变量引入。比如PaymentProcessor持有RiskChecker和InvoiceGenerator实例。
- 分离数据访问与业务逻辑：DAO/Repository类只负责数据库操作，Service类处理业务规则，Controller仅做请求转发。这种分层本身就是SRP的体现。
- 引入领域对象：对于复杂计算或状态管理，可创建专门的Value Object或Domain Service来承载特定能力，如AddressValidator、PriceCalculator等。
借助接口明确职责边界
定义细粒度接口有助于约束类的行为范围。例如：
public interface UserAuthenticator { boolean authenticate(String username, String password); } public interface UserSessionManager { void createSession(User user); void invalidateSession(String token); }实现类各自专注其职，而不是在一个类里实现所有登录相关的功能。这样也便于单元测试和替换实现。
重构示例：从臃肿到清晰
假设有一个UserService类既处理用户注册、又发邮件、又记录日志、还做权限检查。可以这样拆分：
- UserRegistrationService：处理注册流程主逻辑
- EmailService：发送确认邮件
- AuditLogger：记录操作日志
- RolePermissionChecker：验证角色权限
原UserService变为协调者，通过依赖注入调用各小类，自身不再直接实现细节。
基本上就这些。保持类的小而专，不仅提升可读性，也让系统更灵活。关键是持续关注“这个方法真的属于这个类吗”，养成按职责组织代码的习惯。
