移动字段应将频繁被目标类读写的字段迁至其归属类，通过统计访问来源、封装原字段、新增目标字段、逐点替换并验证测试来安全实施，同时规避子类引用、序列化配置、残留逻辑等常见风险。
移动字段（Move Field）是面向对象重构中一项基础但关键的操作，核心目标是让变量回归它真正归属的类——不是看它“放在哪”，而是看它“为谁服务最多”。当一个字段在当前类中几乎不被使用，却频繁被另一个类读写或依赖时，说明它的位置错了，强行留在原处只会拉高耦合、模糊职责。
什么情况下该考虑移动字段
判断依据很直接：统计访问来源。如果超过一半的读写操作来自外部类，尤其是集中在某一个目标类，就值得动手。常见信号包括：
- 源类中只有 getter/setter，几乎没有业务逻辑用到该字段；
- 目标类的多个方法反复通过参数或引用访问该字段；
- 每次修改字段值，都得同步更新目标类里的校验、计算或状态转换逻辑；
- 字段语义明显属于目标实体（比如 CreditLimit 属于 Customer，而非 Order）。
移动过程的关键控制点
不能简单剪切粘贴，否则容易断引用或引发隐藏 bug。重点在于平滑过渡：
- 先封装原字段：若为 public，务必先转为 private + 属性/方法，统一所有访问入口；
- 在目标类中新建同名字段，并配套实现安全的 get/set 方法（注意默认值、空值处理）；
- 确保源类能拿到目标对象实例——要么已有导航属性（如 Order.Customer），要么需临时加一个引用字段；
- 逐个替换调用点，优先改读取逻辑，再改写入逻辑；编译通过后立刻运行单元测试验证行为一致性。
容易踩的坑
移动后功能没坏，不代表重构成功。以下问题常被忽略：
- 子类中直接访问了原字段（尤其 public 或 protected 字段），替换时必须一并覆盖；
- 序列化/ORM 映射配置仍指向旧字段，导致数据库字段或 JSON 输出错乱；
- 字段移动后，原类里残留的初始化逻辑（如构造函数赋默认值）变成无效代码；
- 未同步更新文档、注释或接口契约，后续维护者仍按旧结构理解代码。
移动之后别忘了收尾
字段落地只是第一步。接下来要检查：
- 源类是否因字段移出而变得过于单薄？是否可进一步合并或提炼；
- 目标类是否因此新增了过多责任？比如 Customer 突然要承担订单额度审批逻辑，那就该考虑再拆出 CreditPolicy；
- 相关测试用例是否覆盖了新访问路径，特别是边界值和并发写入场景。
