类体积能说明什么
类过大往往对应职责过多，但体积本身只是信号，不是判据。行数、方法数、字段数容易被量化和展示，却会误导决策：一个职责单一的数据转换类完全可能上千行，一个只有两百行却同时管订单与通知的类才是真正的多职责。真正的判据是变化原因的数量与方向——有多少个不同来源的需求会让这个类被修改。
指标强弱
| 弱指标 | 行数、方法数、字段数、注释密度 |
|---|---|
| 强指标 | 变化原因数量、变更历史广度、依赖方向 |
| 核对方式 | 拆分后各部分是否能各自独立演进 |
| 落地依据 | 每个候选职责能写出一句清晰描述 |
典型使用场景
- 评审发现类越改越大：先查变更历史，看有多少个不相关需求都改过它
- 测试搭建困难：单元测试需要大量替身才能构造，通常说明依赖过多职责
- 代码所有权模糊：同一个类出现在多个团队的工单里，边界与职责需要重划
- 拆分前评估：先为每个候选职责写一句话，写不出来的部分多半是实现细节
- 决定是否值得拆：对低频改动的大类，拆分收益可能低于成本
信号清单
信号清单
# 出现以下任一条，值得进一步核查职责
- 每加一个需求都要改这个类
- 类频繁出现在多个不相关的工单里
- 依赖十种以上外部类型
- 单元测试需要大量替身才能搭建
- 类名里带 and、Manager、Helper、Util判断依据对照
| 观察 | 能否作为拆分依据 | 说明 |
|---|---|---|
| 行数超过阈值 | 否 | 与语言风格、注释密度相关，不能单独作判据 |
| 存在多个变化原因 | 是 | 每个变化原因对应一个潜在职责边界 |
| 变更历史涉及多个团队 | 是 | 所有权交叉是边界不清的典型证据 |
| 方法数量多但都是同一职责 | 否 | 单一职责的长类可以合理存在 |
| 依赖外部类型数量多 | 参考 | 依赖多通常意味着职责多，但需结合变化原因判断 |
拆分前先做一件事：为每个候选职责写一句话描述。写得出来的职责可以独立成类；写不出来的部分通常只是实现细节，强行拆开会产生一批互相依赖的碎片类。
低频改动的大类不一定优先拆。拆分本身有成本，且会让调用方改造范围扩大；如果这个类半年才动一次，把预算投到高频热点模块收益更高。
落地检查清单
- 拆分依据来自变化原因与变更历史，而不是行数
- 每个新类都有能说清职责的命名
- 拆分后各部分可以独立测试与发布
- 为拆分设定可验证的验收指标，例如改动路径减少