单一职责原则（SRP）要求一个类只有一个引起它变化的原因，即只承担一种职责；如User类不应同时处理数据存储、报表生成、邮件发送和密码校验，而应按关注点分离为User、UserRepository、UserService、EmailSender等各司其职的类。
类的职责划分，核心是让每个类只做一件事，并且把这件事做好。这不是限制类的能力，而是明确它的存在理由——当一个类只承担一种责任时，修改它时影响范围小、复用性高、测试也更简单。
什么是单一职责原则（SRP）
单一职责原则是面向对象设计五大原则（SOLID）中的第一个。它指出：一个类应该只有一个引起它变化的原因。换句话说，一个类只应有一个职责，这个职责的变化就是它被修改的唯一理由。
比如：User 类如果既负责存储用户基本信息，又负责生成用户报表、发送邮件、校验密码强度，那它就混杂了“数据模型”“报表生成”“通知服务”“业务规则”多个职责。一旦报表格式改了，或邮件服务商换了，都得动这个类——这明显违背 SRP。
如何识别一个类是否职责过重
观察类中方法的“目的”是否统一。如果出现以下情况，大概率职责不纯：
立即学习“Java免费学习笔记（深入）”；
- 方法命名跨度大：既有 saveToDB()，又有 sendWelcomeEmail()、generateMonthlyReport()
- 引入了不相关的依赖：比如一个本该只操作数据的类，却注入了 MailService 或 ReportGenerator
- 单元测试要模拟多种外部行为：既要 mock 数据库，又要 mock 邮件客户端，还要 mock 文件系统
- 每次需求变更，都要在同一个类里加 if/else 或新分支逻辑，且新增逻辑和原有逻辑语义无关
职责拆分的常见实践方式
不是靠直觉，而是按关注点分离（Separation of Concerns）来重构：
- 数据载体归数据类：如 User 只保留字段、getter/setter、基本验证（如邮箱格式），不做 I/O 或业务决策
- 数据持久化归 Repository 或 DAO：如 UserRepository 负责 save()、findById()，与具体数据库解耦
- 业务规则归 Service：如 UserService 处理注册流程、权限校验、状态转换等，协调多个类协作
- 跨域动作归独立组件：发邮件用 EmailSender，生成 PDF 报表用 ReportBuilder，它们被注入到需要它们的 Service 中
注意：职责 ≠ 功能数量，而看变化原因
一个类可以有很多方法，只要它们都服务于同一目的，就不算违反 SRP。例如 StringCalculator 提供 add()、subtract()、multiply()，职责仍是“字符串形式的四则运算”，变化原因统一（如支持新运算符、兼容空格格式）。
反过来，哪怕只有两个方法，如果一个更新数据库、一个调用第三方风控 API，那它们就属于两个变化轴，应拆开。
基本上就这些。单一职责不是教条，而是帮你在代码变复杂前，提前划清边界。它让类更像一个个可插拔的零件，而不是裹成一团的线团。
