Java如何实现单一职责原则详解

单一职责原则（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 实现类即可，不碰已有代码。

警惕“伪单一职责”陷阱：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 中，导致开关逻辑分散 —— 应封装为 FeatureToggle Bean，由它统一读取并提供 isEnabled("user-profile-v2") 方法

职责越清晰，越难靠“加个注解”糊弄过去；而每次想偷懒用注解替代职责划分，都在给后续重构埋雷。