构造函数中的外部副作用答案

【问题标题】：external side effect in constructor构造函数中的外部副作用
【发布时间】：2011-04-09 09:45:21
【问题描述】：

看看这段代码：

#include <framework_i_hate.h>
int main() {
  XFile file("./my_file.xxxx", "create");
  XObject object("my_object");
  // modify the object
  object.Write();
}

尝试猜测object 将被保存在哪里......是的，你猜对了。我觉得这太神奇了，我想写object.Save(file)之类的东西，但没有必要。显然framework_i_hate.h 内部有一个全局变量，它在file 构造函数期间被修改。您如何看待构造函数内部的这种副作用？

如何隐藏这种行为？

猜猜框架的人的奖励。

【问题讨论】：

@aaa：我认为回答这个问题的最佳方式是这样做，是的。
我应该标记这个[root-framework]吗？最后，这仍然是太多的咆哮并且没有真正的用处。

标签： c++ constructor side-effects

【解决方案1】：

帖子非常混乱难以理解，最后的问题非常修辞。全局变量是邪恶的，还有什么要补充的？

【讨论】：

【解决方案2】：

对此还不够明显的说法是：这是一个相当讨厌的副作用，因为：

产生的行为是出乎意料的，根本无法预测，除非您非常了解该框架。
全局程序状态在面向对象编程中通常不是一个好主意。（事实上，全局状态可能从来都不是一个好主意，所以如果可以的话最好避免它。）
这个框架很可能也不是线程安全的。（想想当两个并发线程都创建一个XFile 对象时会发生什么，然后其中一个线程写入一个XObject...它最终会保存在哪里？）

虽然此线程被标记为 C++ 而不是关于 .NET，但我之前曾以不那么严重且更加理智的形式看到这种“反模式”，即使用 DB 事务范围。

【讨论】：

【解决方案3】：

我更愿意看到 XFile 和 XObject 之间的关系是明确的，我同意这个“魔法”被隐藏得太好了。我还质疑为什么要给对象命名，除非 API 的其他部分具有重要的名称。

全局变量被鄙视的原因有很多，这只是一个例子。

【讨论】：