适合用字段取代子类的核心标准是：子类间仅在常量返回值上不同且值不随实例状态变化；子类无行为逻辑、无状态依赖、未被用于多态分发；迁移需分步进行，含工厂函数、私有字段、方法上移、调用替换及安全删除。
当子类只负责返回几个固定值，比如性别、状态或类型码，而没有自己的行为逻辑或可变数据时，保留它们反而增加理解成本。直接用字段替代更轻量、更易维护。
什么情况下适合用字段取代子类
核心判断标准是：子类之间**仅在常量返回值上不同**，且这些值不随实例状态变化。
- 子类中只有类似
getGenderCode()、isMale()这类始终返回"M"或true的方法 - 没有重写涉及计算、I/O、依赖注入或状态变更的行为方法
- 外部代码没有基于
instanceof Male做分支处理，或这类检查可以统一收口到超类中 - 子类未被用于多态分发（如策略模式中的具体策略类）
关键操作步骤
不是直接删子类，而是分步迁移，确保每次改动都可测试、可回退。
- 先为超类添加工厂函数（如
Person.createMale()），把子类构造逻辑封装进去 - 在超类中新增私有字段（如
_genderCode），并提供受保护的构造入口来初始化它 - 将子类中每个常量方法（如
getGenderCode()）移至超类，改为返回该字段 - 逐步替换所有对子类构造的直接调用，改为调用工厂函数
- 确认无残留的
instanceof检查后，删除子类文件，并移除相关 import
要注意的细节
看似简单，但容易在边界处出错。
- 如果客户端代码用
instanceof判断类型，不能直接删——先提取成超类的一个查询方法（如isMale()），再让所有调用点改用它 - 字段命名要明确语义，避免用模糊名如
type；推荐_genderCode或_roleKind这类带上下文的名称 - 若原字段需保持不可变，可在超类中声明为
final（Java）或readonly（C#），并在构造时一次性赋值 - 测试重点不是功能是否还通，而是“所有原来走 Male 分支的逻辑，现在是否仍走同一路径”
和反向重构的区别
这个手法与“以子类取代类型码”正好相反，适用阶段也不同。
- “以子类取代类型码”适用于类型码已存在、且行为差异明显，需要扩展性时
- “以字段取代子类”适用于子类已沦为“枚举壳”，实际没带来多态收益，只是历史遗留
- 选哪个，取决于当前代码的演化阶段：新增能力倾向建子类，收敛逻辑倾向收字段
