重构面向对象代码时保持行为不变的核心是用可验证的方式控制变化范围，必须先补全单元测试，尤其覆盖多态调用、虚函数语义、继承边界和组合后的接口一致性，否则极易破坏隐式契约。
重构面向对象代码时保持行为不变，核心不是“不改逻辑”，而是“用可验证的方式控制变化范围”。只要没做自动化回归测试，所谓“行为不变”就是主观判断，极大概率出错。
先写或补全单元测试，否则别碰 class 或 virtual 函数
面向对象代码的行为依赖隐式契约：比如 Base::draw() 被子类重写后，调用方是否依赖返回值、异常抛出、副作用（如修改全局状态）、执行顺序？这些不会在函数签名里体现，但测试能捕获。
- 没有测试时，优先为关键路径补最小闭环测试：构造对象 → 调用一个公有方法 → 断言输出或状态变更
- 若原项目用
gtest，直接在TEST中覆盖多态调用场景，例如：std::unique_ptr<base> p = std::make_unique<derived>(); p->process();</derived>，确保结果与重构前一致 - 避免只测“能编译”或“不崩溃”——要测具体返回值、成员变量值、外部依赖调用次数（可用 mock）
继承结构重构必须守住 public 接口和 virtual 语义边界
改基类或派生类时，最容易破坏行为的地方是虚函数表布局和访问控制变化。哪怕只是把 protected 成员改成 private，也可能导致子类编译失败或静默调用父类默认实现。
- 检查所有
virtual函数是否仍被正确重写：子类中漏掉override标记，或父类加了新纯虚函数但未在子类实现，会导致链接错误或运行时pure virtual function called - 不要在基类构造/析构函数中调用
virtual函数——此时动态绑定失效，实际调用的是当前正在构造/析构的类的版本，极易引发未定义行为 - 若需提取共用逻辑，优先用
final非虚函数封装，再由虚函数委托，而非直接修改虚函数体
用组合替代继承时，小心 is-a 和 has-a 的语义漂移
把 class Button : public Widget 改成 class Button { Widget widget_; } 看似安全，但一旦外部代码做了 dynamic_cast<widget>(&btn)</widget> 或依赖 Button* 可隐式转为 Widget*，行为就变了。
- 搜索全部
dynamic_cast、static_cast到基类的用法，确认它们是否属于合法多态使用场景 - 如果基类有非虚析构函数，而你正用指针管理对象，组合后必须确保
Widget的析构仍被正确调用（比如显式调用或用std::shared_ptr管理生命周期） - 接口一致性比结构一致性更重要：组合后，
Button::render()内部调widget_.render()没问题，但若Widget::render()抛异常而Button::render()原来不抛，就得补try/catch或重新设计契约
真正难的从来不是“怎么改”，而是“怎么确认没改错”——尤其是多态调用链中跨多个编译单元、依赖 RTTI 或虚函数表偏移的代码。每次改动后，跑一遍老测试 + 手动触发几个典型运行时路径，比盯着 diff 有用得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
