单一职责原则（SRP）指一个类应仅有一个引起它变化的原因；如Order类应只管订单数据，计算、开票、通知等职责需按变化动因拆分为OrderCalculator、InvoiceGenerator、NotificationService等独立类。
类的职责划分，核心是“一个类只做一件事”，这件事要足够具体、边界清晰、可被独立理解与测试。职责过宽会导致类臃肿、复用困难、修改风险高；职责过窄又会引发大量琐碎类，增加协作成本。关键不在“拆多细”，而在“是否自然内聚、变化原因是否一致”。
单一职责原则（SRP）不是指“一个类只有一个方法”
SRP 的本质是“一个类应该只有一个引起它变化的原因”。比如，一个 Order 类负责订单数据结构、计算总价、生成发票、发送邮件——这明显混杂了实体建模、业务计算、外部集成多种变化动因。一旦税务规则变（影响计算）、邮件服务商换（影响发送）、订单字段增（影响结构），都得改同一个类。
更合理的拆分：
- Order：仅描述订单事实（id、items、createdAt 等）
- OrderCalculator：封装所有价格、折扣、税费逻辑
- InvoiceGenerator：专注格式化开票数据，不碰业务规则
- NotificationService：统一处理邮件/SMS/站内信等通知渠道
按变化维度识别职责边界
实际开发中，可从这几个常见变化源头反推职责是否该分离：
- 业务规则变动（如促销策略调整）→ 单独抽为策略类（PromotionStrategy）或规则引擎
- 数据存储方式变更（如从 MySQL 换到 MongoDB）→ 将数据访问逻辑封装进 Repository 或 DAO，与领域对象解耦
- 外部接口升级（如微信支付 SDK 迭代）→ 用适配器包装，暴露稳定接口给内部调用
- 前端展示需求变（如新增字段、排序方式）→ 视图模型（DTO 或 VO）与领域模型分离
警惕“伪职责分离”和过度设计
不是所有拆分都合理。以下情况需谨慎：
- 一个只有两三个简单 getter 的“工具类”，只为满足 SRP 而拆出，反而增加认知负担
- 把 UserService 拆成 UserCreationService、UserQueryService、UserDeletionService，但三者共用同一套校验、事务、日志逻辑，徒增模板代码
- 过早引入复杂模式（如 CQRS、事件溯源），而当前系统连百行业务逻辑都没有
判断标准很简单：拆分后，每个类是否更容易被单独理解、测试、复用？改动一个功能时，是否只需动一两个类，且不会波及其他无关模块？
借助构造函数与依赖注入明确职责依赖
类知道自己需要什么，比“自己创建一切”更能体现职责清晰。例如：
❌ 不推荐：
public class OrderProcessor {
public void process(Order order) {
PaymentService ps = new AlipayService(); // 自己造依赖
ps.pay(order);
}
}
✅ 更清晰：
public class OrderProcessor {
private final PaymentGateway payment;
public OrderProcessor(PaymentGateway payment) {
this.payment = payment; // 明确声明“我负责流程编排，支付由你负责”
}
}
这种写法让类的协作关系一目了然，也便于单元测试（可注入 Mock 支付网关）。
