为什么构造函数中的while（true）循环实际上不好？

尽管是一个普遍的问题，但我的范围是C＃，因为我知道像C ++这样的语言在构造函数执行，内存管理，未定义的行为等方面具有不同的语义。

有人问我一个有趣的问题，对我来说不容易回答。

为什么（或者根本不？）让类的构造函数开始永无止境的循环（即游戏循环）被认为是不好的设计？

有一些与此有关的概念：

• 像最小惊讶原则一样，用户并不希望构造函数具有这种行为。
• 单元测试比较困难，因为您无法创建此类或将其注入，因为它永远不会退出循环。
• 从概念上讲，循环的结束（游戏结束）是构造函数完成的时间，这也是奇怪的。
• 从技术上讲，此类除了构造函数外没有其他公共成员，这使它很难理解（尤其是对于没有可用实现的语言）

然后是技术问题：

• 构造函数实际上从未完成，所以GC在这里发生了什么？这个对象已经在Gen 0中了吗？
• 由于基本构造函数从不返回，因此无法或至少非常复杂地从此类派生

这样的方法是否存在更明显的弊端或弊端？

构造函数的目的是什么？它返回一个新构造的对象。无限循环有什么作用？它永远不会回来。如果构造函数根本不返回，该构造函数如何返回该新构造的对象？不行

因此，一个无限循环破坏了构造函数的基本契约：构造某些东西。

这样的方法是否存在更明显的弊端或弊端？

当然是。它是不必要的，意外的，无用的，毫不含糊的。它违反了类设计的现代概念（内聚，耦合）。它破坏了方法协定（构造函数具有定义的任务，而不仅仅是一些随机方法）。它当然不能很好地维护，将来的程序员将花费大量时间试图了解正在发生的事情，并试图猜测这样做的原因。

就您的代码不起作用而言，这绝不是“错误”。但是从长远来看，由于使代码难以维护（例如，难以添加测试，难以重用，难以调试，难以扩展等），从长远来看，这可能会带来巨大的辅助成本（相对于最初编写代码的成本）。 ）。

专门针对软件开发方法进行了许多/最现代的改进，以简化编写/测试/调试/维护软件的实际过程。所有这些都可以通过诸如此类的东西来规避，因为它们“有效”，所以代码被随机放置。

不幸的是，您经常会遇到完全不了解这一切的程序员。它起作用了，就是这样。

用类比结束（另一种编程语言，此处的问题是计算2+2）：

$sum_a = `bash -c "echo $((2+2)) 2>/dev/null"`;   # calculate
chomp $sum_a;                         # remove trailing \n
$sum_a = $sum_a + 0;                  # force it to be a number in case some non-digit characters managed to sneak in

$sum_b = 2+2;

第一种方法有什么问题？在相当短的时间内返回4；它是正确的。反对意见（以及开发人员可能提出的所有通常理由）：

• 较难阅读（但是，嘿，一个好的程序员可以很容易地阅读它，我们一直都是这样做的；如果您愿意，我可以将其重构为方法！）
• 速度较慢（但这不是在时间上至关重要的地方，因此我们可以忽略它，此外，最好仅在必要时进行优化！）
• 使用更多资源（新进程，更多RAM等-但是dito，我们的服务器足够快）
• 引入依赖关系bash（但是无论如何它永远不会在Windows，Mac或Android上运行）
• 以及上述所有其他原因。

您在问题中给出了足够的理由将这种方法排除在外，但这里的实际问题是“这种方法是否存在明显更糟或更糟的东西？”

我的第一个想法是，这毫无意义。如果您的构造函数永远无法完成，则程序的其他部分都无法获得对所构造对象的引用，因此将其放入构造函数而不是常规方法的逻辑是什么。然后我想到，唯一的区别是您可以在循环中允许对循环进行部分构造的this转义引用。尽管这不严格限于这种情况，但可以保证，如果允许this转义，则这些引用将始终指向未完全构造的对象。

我不知道有关这种情况的语义是否在C＃中得到了很好的定义，但我认为这并不重要，因为大多数开发人员都不希望尝试深入研究。

+1至少令人惊讶，但这对新开发人员来说是一个很难理解的概念。从实用的角度讲，很难调试构造函数中引发的异常，如果对象未能初始化，则将不存在该对象，以供您检查该构造函数的状态或从该外部进行记录。

如果您需要执行这种代码模式，请在类上使用静态方法。

当从类定义实例化对象时，存在构造函数来提供初始化逻辑。之所以构造此对象实例，是因为它是一个容器，它封装了希望从其余应用程序逻辑中调用的一组属性和功能。

如果您不打算使用要“构造”的对象，那么首先实例化该对象的意义是什么？在构造函数中有效地使用while（true）循环意味着您永远都不想完成它……

C＃是一种非常丰富的面向对象语言，具有许多不同的构造和范例，供您探索，了解您的工具以及何时使用它们，底线是：

在C＃中，不要在构造函数中执行扩展或永无止境的逻辑，因为...还有更好的选择

本质上没有什么不好的。但是，重要的是您为什么选择使用此构造的问题。通过这样做您得到了什么？

首先，我不会谈论while(true)在构造函数中使用。有绝对没有错，使用语法构造。但是，“在构造函数中启动游戏循环”这一概念可能会引起一些问题。

在这种情况下，让构造函数简单地构造对象并具有调用无限循环的函数是很常见的。这为您的代码用户提供了更大的灵活性。例如，您可能会限制使用对象。如果某人希望在其类中拥有一个成员对象，即“游戏对象”，则他们必须准备好在其构造函数中运行整个游戏循环，因为他们必须构造该对象。这可能导致折磨编码以解决此问题。在一般情况下，您无法预先分配游戏对象，然后再运行它。对于某些程序而言，这不是问题，但是有些程序类希望能够预先分配所有内容，然后调用游戏循环。

编程的经验法则之一是使用最简单的工具来完成这项工作。这不是一成不变的规则，但这是一个非常有用的规则。如果一个函数调用就足够了，为什么还要构造一个类对象呢？如果我看到使用的功能更强大的复杂工具，我认为开发人员有理由使用它，并且我将开始探索您可能正在做的奇怪技巧。

在某些情况下，这可能是合理的。在某些情况下，构造函数中有一个游戏循环对您而言是真正直观的。在这种情况下，您可以运行它！例如，您的游戏循环可能嵌入到一个更大的程序中，该程序构造类以体现一些数据。如果必须运行游戏循环来生成该数据，则在构造函数中运行游戏循环可能非常合理。只是将其视为一种特殊情况：这样做是有效的，因为总体程序使下一个开发人员可以直观地了解您的操作以及原因。

我的印象是，一些概念混淆了，并导致了一个措辞不太好的问题。

类的构造函数可能会启动一个新线程，该线程将“永远”结束（尽管我更喜欢使用它while(_KeepRunning)，while(true)因为我可以在某个地方将布尔成员设置为false）。

您可以将创建和启动线程的方法提取到它自己的函数中，以便将对象构造和工作的实际开始分开-我更喜欢这种方式，因为我可以更好地控制对资源的访问。

您还可以查看“活动对象模式”。最后，我想问题是针对何时启动“活动对象”的线程的，而我的偏好是将构造分离并开始进行更好的控制。

您的对象使我想起了Tasks。任务对象有一个构造函数，但它也有一堆的静态工厂方法，如：Task.Run，Task.Start和Task.Factory.StartNew。

这些与您要执行的操作非常相似，这很可能就是“惯例”。人们似乎遇到的主要问题是对构造函数的这种使用使他们感到惊讶。@JörgWMittag说它违反了一项基本合同，我想这意味着Jörg非常惊讶。我同意，仅此而已。

但是，我想建议OP尝试使用静态工厂方法。惊喜消失了，这里没有基本的合约在危急中。人们习惯于使用静态工厂方法来做特殊的事情，并且可以对它们进行相应的命名。

您可以提供允许进行细粒度控制的构造函数（如@Brandin所建议的，类似var g = new Game {...}; g.MainLoop();，可以容纳那些不想立即开始游戏并且可能想先通过游戏的用户。您可以编写类似var runningGame = Game.StartNew();开始游戏的内容。立即轻松。

为什么构造函数中的while（true）循环实际上不好？

一点都不坏。

为什么（或者根本不？）让类的构造函数开始永无止境的循环（即游戏循环）被认为是不好的设计？

您为什么要这样做？说真的 该类具有一个功能：构造函数。如果您只需要一个函数，这就是我们拥有函数而不是构造函数的原因。

您提到了一些自己反对它的明显原因，但忽略了最大的原因：

有更好和更简单的选择来实现相同的目的。

如果有两个选择，一个更好，那么选择多少就无关紧要，您选择了更好的一个。顺便说一句，这就是为什么我们不几乎从来没有使用goto。

构造函数的目的是构造您的对象。在构造函数完成之前，原则上使用该对象的任何方法都是不安全的。当然，我们可以在构造函数中调用对象的方法，但是每次执行此操作时，我们都必须确保这样做对处于当前半休假状态的对象有效。

通过将所有逻辑间接放入构造函数中，您会给自己增加更多的负担。这表明您没有设计初始化之间的区别，并且使用得不够好。