类拆分应以应对需求变更为目标，按变化原因、调用方角色、逻辑层级三原则进行：隔离不同变更节奏的职责，接口随使用者分化，将“怎么做”与“谁来做”分离，并控制拆分节奏，只解决当前问题。
需求变更是常态，类拆分不是为了“看起来更细”，而是让每次变更只影响最小范围。关键在于识别变化点、划清职责边界、隔离依赖关系。
按变化原因拆分：一个类只响应一类变更
比如一个 Person 类最初只有 name 和 age，后来要加 email、phone、address，再后来还要支持不同国家的身份证格式——这些字段的变更节奏完全不同。email 可能频繁调整校验规则，而 address 结构可能随业务扩展大幅变动。
- 把稳定身份信息（如 id、注册时间）保留在 Person 实体类中
- 将联系信息抽成独立的 ContactInfo 值对象，不可变、带完整校验逻辑
- 把地址相关操作（如标准化、地理编码）封装进 AddressService，不污染 Person
按调用方角色拆分：接口跟着使用者走
别让一个接口同时被前端、报表、风控三个系统调用。它们需要的数据和操作完全不同，硬塞在一起只会导致每次改一个功能，其他模块都得重新测试。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 前端登录模块只需要 authenticate() 和 refreshToken() → 提取为 UserAuthenticator
- 运营后台要冻结账号、导出名单、审核资料 → 定义 UserAdminService
- 营销系统只管邀请码生成与核销 → 单独建 InviteCodeManager
- 所有实现类不再写
throw new UnsupportedOperationException()，也不用空实现无关方法
按逻辑层级拆分：把“怎么做”从“谁来做”里拎出来
常见陷阱是让存储类（如 PersonDataStorage）直接调用 person.getName() 和 person.getAge()。一旦 Person 加字段，所有存储类全得改——这不是职责问题，是抽象缺失。
- 新增 PersonWriter 类，专责把 Person 转成文本/JSON/CSV 格式
- PersonDataStorage 只依赖 PersonWriter，完全不碰 Person 的 getter
- 后续加 email 字段？只改 PersonWriter.write() 一行，其他类零修改
- 这个 writer 还可复用于日志打印、API 响应组装等场景，复用性自然提升
控制拆分节奏：不为未来猜，只为当前解
不要一上来就设计泛型 DataWriter
- 先做最小可行拆分：比如只提取 PersonWriter，验证它能否隔离变更
- 观察三个月内哪些字段/行为确实频繁变动，再决定是否进一步细分（如拆出 ContactWriter、ProfileWriter）
- 公共接口（如 getter）只暴露稳定语义，age 就是“出生至今的整年数”，不是“数据库 age 字段值”
- 若 age 含义可能变成“入职年限”，那就重命名为 getTenureInYears()，而不是靠注释或文档去说明
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
