构造函数中的外部副作用

Question

看看这段代码：

#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构造函数中被修改。您如何看待构造函数中的这个副作用？

如何隐藏此行为？

谁猜测框架的奖金。

Answer 1

非常混乱难以理解的帖子和问题到底是非常夸张的。 全局变量是邪恶的，还有什么可以添加？

Answer 2

关于这一点可以说什么还不够明显：这是一个相当讨厌的副作用，因为：

• 产生的行为是意料之外的，根本不可预测，除非你很了解这个框架。

• 全局程序状态在面向对象编程中通常不是一个好主意。 （事实上​​，全球国家可能永远不是一个好主意，所以如果可以，最好避免它。）

• 这个框架很可能也不是线程安全的。 （想想当两个并发线程每个都创建一个XFile对象时会发生什么，然后其中一个线程写一个XObject ...它最终会被保存在哪里？）

  < / LI>

虽然这个线程被标记为C ++而不是.NET，但我之前已经看到了这种“反模式”，其形式不那么严格，更加理智，即使用数据库事务范围。

Answer 3

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

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