C++中更新源存为引用成员与每次传参给update的优劣对比

核心优势 #

• 减少重复传参的样板代码：高频触发update()的场景下，无需在每个调用点重复获取并传入Source实例，同时从实现层面避免了调用点误传其他无关Source实例的低级错误。
• 简化跨层参数透传成本：如果update()的调用链需要经过多层中间逻辑，每次传参的写法会要求每一层函数签名都新增Source引用的透传参数；将Source引用存为成员后，这部分跨层的参数传递逻辑可以直接省略，减少不必要的接口耦合。
• 匹配固定绑定的业务语义：如果设计上ObjectThatNeedsUpdates从生命周期开始就永久绑定某一个特定Source实例，存储引用的写法比每次临时传参更贴合实际的依赖关系，不会出现依赖关系和业务设计错位的问题。

存在的不足 #

• 引入隐蔽的生命周期风险：C++的成员引用不会自动管理指向对象的生命周期，如果被绑定的Source实例先于ObjectThatNeedsUpdates实例被销毁，类内部就会持有悬空引用，一旦调用update()直接触发未定义行为。这类问题往往比临时传参的同类隐患难排查得多——临时传参时如果传了已经销毁的悬空对象，通常问题出在紧邻的调用点，很容易被编译器告警或静态检查工具捕获；但存成员引用的悬空问题是构造时埋下的，可能隔了很久的业务流程才触发，排查成本极高。
• 损失设计灵活性：一旦将Source引用存为成员，类实例从“可适配任意Source、运行时指定依赖”变成了“构造完成即永久锁死绑定”。如果后续需要让同一个实例切换绑定的Source（比如更换数据源、单元测试时替换mock数据源），因为C++的引用无法重新绑定，只能重新构造整个类实例，无法做到运行时动态调整依赖。
• 破坏C常规值语义：类内只要有const引用类型的非静态成员，编译器就会直接删除默认构造函数，同时也不会自动生成拷贝赋值运算符（毕竟引用一旦绑定就不能重新赋值）。如果后续需要把这个类的实例放到std::vector这类标准容器里，或者需要对实例做拷贝、赋值操作，会遇到一堆不必要的语法限制，完全偏离C普通值类的设计习惯。
• 隐式化依赖关系：每次传参的写法下，update()函数的签名会显式标明它对Source的依赖关系，读代码时能直观知道调用该方法需要准备什么输入；存为成员引用后，依赖关系被藏在类的私有成员中，外部逻辑很难直观感知到这个类对外部Source实例的强依赖，多人协作场景下很容易出现构造时传入无效Source、运行时才爆错的问题，抬高维护成本。

内容的提问来源于stack exchange，提问作者JensB