单一职责原则（SRP）指一个类应仅有一个引起它变化的原因；常见违反表现是Service类混杂校验、DB、第三方调用等多职责；识别方式包括组合方法名、多类型依赖导入、高mock数量及跨模块修改；应通过职责链接口分离，警惕伪单一职责，并避免Spring注解导致的职责耦合。
单一职责原则（SRP）不是“一个类只能有一个方法”，而是“一个类应该只有一个引起它变化的原因”。在 Java 实际开发中，违反 SRP 最常见的表现不是代码量多，而是 Service 类里混着参数校验、数据库操作、第三方调用、缓存逻辑和日志埋点——所有这些本该由不同角色承担的职责，全挤在同一个 updateUser() 方法里。
怎么识别一个类已经违背了 SRP
观察类中是否存在以下任意一种现象：
- 方法签名里频繁出现
xxxWithCache、xxxAndNotify、xxxThenValidate这类组合动词 -
import列表同时包含RedisTemplate、JdbcTemplate、RestTemplate和LogFactory - 单元测试类中，一个
@Test方法要 mock 4 个以上不同类型的依赖（比如UserService测试里还得 mock 邮件服务、风控服务、ES 客户端） - 修改短信发送逻辑时，必须同步改
UserServiceImpl，而不是只动SmsSender
把“用户更新”拆成可替换的职责链
以 updateUserProfile() 为例，原始写法常把所有事塞进一个方法；符合 SRP 的做法是显式分离职责，并通过接口聚合协作：
public interface UserProfileUpdater {
UserProfile update(UserProfile profile);
}
public class UserProfileValidator implements UserProfileUpdater {
private final UserProfileUpdater next;
public UserProfileValidator(UserProfileUpdater next) { this.next = next; }
@Override
public UserProfile update(UserProfile profile) {
if (profile.getPhone() == null) throw new IllegalArgumentException("phone required");
return next.update(profile);
}
}
public class UserProfilePersister implements UserProfileUpdater {
private final JdbcTemplate jdbcTemplate;
public UserProfilePersister(JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; }
@Override
public UserProfile update(UserProfile profile) {
jdbcTemplate.update("UPDATE user SET ...", ...);
return profile;
}
}
// 使用时组装：new UserProfileValidator(new UserProfilePersister(jdbcTemplate))
这样每段逻辑都只对一类变更敏感：校验规则变 → 只改 UserProfileValidator；数据库字段变 → 只动 UserProfilePersister；后续加审计日志？新增 AuditLogger 实现类即可，不碰已有代码。
立即学习“Java免费学习笔记（深入）”；
警惕“伪单一职责”陷阱：Getter/Setter 不等于职责
很多人以为把 getUserName() 和 sendEmail() 拆到两个类就满足 SRP，但若这两个方法都服务于“用户通知场景”，它们仍共享同一变化原因（比如通知渠道从邮件切换到企微）。真正判断依据是：当业务方说“以后所有通知都要走钉钉”时，哪些类必须被修改？
- 如果只有
DingTalkNotifier被改，说明职责隔离成功 - 如果
UserServiceImpl、OrderController、RefundTask全都得加钉钉适配逻辑，说明通知职责仍被到处复制，没抽象成独立模块 - 此时应提取统一的
NotificationService接口，让各业务方只依赖它，而非具体实现
Spring 中最容易破坏 SRP 的配置点
Spring 的自动装配机制会让职责边界变得模糊。常见问题包括：
-
@Transactional加在 Service 方法上，导致事务管理逻辑与业务逻辑耦合 —— 应考虑用 AOP 或声明式事务切面单独管理 -
@Scheduled直接写在 Service 类里，把调度策略（何时执行）和执行逻辑（做什么）绑死 —— 调度应由ScheduledTaskRegistrar或 Quartz 管理，Service 只暴露无状态的execute() -
@Value("${feature.flag.enabled}")出现在多个 Service 中，导致开关逻辑分散 —— 应封装为FeatureToggleBean，由它统一读取并提供isEnabled("user-profile-v2")方法
职责越清晰，越难靠“加个注解”糊弄过去；而每次想偷懒用注解替代职责划分，都在给后续重构埋雷。
