单一职责原则（SRP）指一个类应仅有一个引起它变化的原因；若密码校验、数据库切换、通知方式变更等均需修改同一类，则违反SRP，需按校验、仓储、通知、日志等职责拆分。
单一职责原则（SRP）不是“一个类只能写一个方法”，而是“一个类应该只有一个引起它变化的原因”。 这句话听起来抽象，但落到代码上，就看：当你改密码校验规则、换数据库、切短信为邮件、加日志埋点——这些修改是否都得动同一个类？如果答案是“是”，那这个类已经违反了SRP。
怎么一眼识别违反SRP的Java类
观察类里是否混杂以下任意两类及以上行为：
- 数据校验逻辑（如
validatePassword()）和数据持久化（如saveToMySQL()） - 业务主流程（如注册）和副作用操作（发短信、写日志、调第三方）
- 领域模型（
User）直接包含技术实现（如sendEmail()或saveToDatabase()） - 接口定义中同时暴露查询能力（
getCourseVideo()）和管理能力（refundCourse()）
典型反例：UserService.register() 方法里既做参数检查、又存DB、又发通知、又打日志——它有至少4个独立的变更源头，任何一个调整都可能波及其他。
重构时该拆成哪些类，而不是随便分
拆分不是为了数量多，而是让每个类的“变化原因”彼此隔离。推荐按职责类型归类：
立即学习“Java免费学习笔记（深入）”；
- 校验类（如
UserValidator）：只响应产品规则变更（如“密码必须含大小写字母+数字”） - 仓储类（如
UserRepository）：只响应存储技术变更（MySQL → Oracle → MongoDB） - 通知类（如
SmsNotifier/EmailNotifier）：只响应运营渠道变更（短信→邮件→企微） - 日志类（如
OperationLogger）：只响应运维规范变更（本地文件→ELK→SLS）
原 UserService 变成协调者，只负责组合调用，不掺和具体实现。这样新增微信通知，只需加 WechatNotifier，完全不用碰已有代码。
接口层面的SRP常被忽略
接口比类更容易“悄悄”违反SRP。比如一个 ICourse 接口既定义 getCourseName()（读取信息），又定义 refundCourse()（修改状态），还定义 studyCourse()（执行行为）——这三种操作面向的对象、权限、生命周期完全不同。
更合理的做法是拆成：
-
ICourseInfo：只读属性（getCourseName(),getCourseVideo()） -
ICourseManager：状态变更（refundCourse(),cancelEnrollment()） -
ICoursePlayer（可选）：行为执行（studyCourse(),pause(),resume()）
这样，未付费用户只依赖 ICourseInfo，连退款接口的编译依赖都没有，安全性与解耦度都提升。
真正难的不是“知道要拆”，而是判断“拆到哪一层算合理”。拆太细（比如为每个字段建一个 UserNameUpdater 类）会让调用链过长；拆太粗（比如所有用户操作塞进一个 UserFacade）又回到老路。关键看：两个逻辑是否**因不同角色、不同时间、不同原因**而修改——如果是，它们就不该在同一个类里。
