单一职责原则（srp）要求每个类只对一种变化原因负责，核心是按用户可感知的完整业务动作（如“用户注册”“密码重置”）划界拆分，而非按技术层切分；通过git历史识别高频修改点，提取为命名明确的业务服务类，并用接口和事件解耦，渐进式迁移。

单一职责原则（SRP）不是“让类变小”的表面功夫，而是让每个类只对一种变化原因负责。一个上千行的类之所以危险，不是因为它长，而是因为改一处可能牵动八方——比如法务要求加强邮箱校验，结果订单创建逻辑突然报错；或者换短信服务商，连用户注册的数据库事务都得重测。拆分的核心，是识别“谁会因为什么理由去改它”。

按真实业务动作划界，别按技术层切

打开那个臃肿类，先别读代码，只扫方法名和字段名。把功能归到用户能感知的业务动作里：

• “用户注册”——含表单校验、数据补全、入库、欢迎通知
• “密码重置”——含令牌生成、邮箱发送、新密码加密保存
• “第三方登录绑定”——含 OAuth 流程、冲突检测、关系建立
• “登录态管理”——含 token 签发、刷新、失效清理

这些不是技术操作，而是系统对外提供的完整能力。每个动作对应一个独立业务域，就该是一个独立类（或服务）。别拆成“DAO类”“Utils类”“Helper类”——那只是把混乱从一处挪到多处。

从 Git 历史里找第一批拆分目标

翻近半年的提交记录，找出被修改最频繁的方法。高频变更点就是职责混杂的证据：

• 订单创建方法里夹着库存扣减、优惠券校验、积分发放、短信通知
• 用户更新接口里同时处理头像上传、资料保存、消息推送、行为埋点

这些就是第一批必须剥离的对象。为每个职责新建类，命名直指业务意图：如 CouponValidationService、InventoryDeductionService。原类退化为协调者，只保留调用顺序和错误兜底。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

用接口+事件解耦，不靠 new 和私有字段通信

拆完若还靠 new 实例或直接访问字段，等于没拆。正确做法：

• 为每个新职责定义接口，如 EmailVerificationService
• 原类持有该接口引用，运行时注入具体实现（Spring Bean 或手动传入）
• 新类之间不互相调用，改用事件协作：注册成功后发 UserRegisteredEvent，由监听器触发邮件发送

这样，后续替换邮件为短信、或改用队列异步发，只需新增一个实现类并调整配置，完全不影响注册主流程。

保留胶水层，渐进迁移不求一步到位

别幻想一次性全拆干净。把原类当作过渡协调器，每次拆出一个职责就：

• 删掉原类中对应逻辑块
• 补上单元测试，覆盖新旧路径一致的行为
• 给旧逻辑打上 @Deprecated 注解，并注明下个迭代移除

允许短期重复（比如新旧两套日志写法并存），只要新逻辑已上线且稳定，旧逻辑就进入淘汰倒计时。重构不是大爆炸，而是可控演进。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南