构造函数应该有多复杂

我正在与我的同事讨论一个构造函数可以完成多少工作。我有一个类B，它内部需要另一个对象A。对象A是类B需要完成其工作的几个成员之一。它的所有公共方法都依赖于内部对象A。有关对象A的信息存储在DB中，因此我尝试通过在构造函数中的DB上进行查找来进行验证和获取。我的同事指出，除了捕获构造函数参数外，构造函数不应做太多工作。由于如果使用构造函数的输入未找到对象A，所有公共方法都将失败，因此我认为与其允许创建实例并在以后失败，不如让它早于构造器。

别人怎么想？如果这有任何区别，我正在使用C＃。

阅读是否有理由在构造函数中完成对象的所有工作？我想知道通过转到DB来获取对象A是“使该对象准备好使用所需的任何其他初始化”的一部分，因为如果用户将错误的值传递给构造函数，我将无法使用其任何公共方法。

构造函数应实例化对象的字段，并进行其他任何必要的初始化，以使对象可以立即使用。这通常意味着构造函数很小，但是在某些情况下这将需要大量的工作。

您的问题由两个完全独立的部分组成：

我应该从构造函数中引发异常，还是应该让方法失败？

显然，这是快速失败原则的应用。与必须找出方法失败的原因相比，使构造函数失败更容易调试。例如，您可能已经从代码的其他部分获得了已经创建的实例，并且在调用方法时遇到错误。显然对象创建错误吗？没有。

至于“在try / catch中包装呼叫”问题。例外是例外。如果知道某些代码将引发异常，则无需将代码包装在try / catch中，而是在执行可能引发异常的代码之前验证该代码的参数。异常仅是为了确保系统不会进入无效状态。如果知道某些输入参数可能导致无效状态，请确保这些参数永远不会发生。这样，您只需要在逻辑上可以处理异常的地方进行尝试/捕获，通常就在系统边界上。

我可以从构造函数访问“系统的其他部分，例如DB”。

我认为这违背了最小惊讶原则。没有多少人会期望构造函数访问数据库。所以不，您不应该这样做。

啊。

构造函数应该做的尽可能少-问题是构造函数中的异常行为很尴尬。很少有程序员知道什么是正确的行为（包括继承方案），并且强迫用户尝试/捕获每个实例都非常痛苦。

这有两个部分，在构造函数中和使用构造函数。这在构造函数中很尴尬，因为发生异常时您不能在那里做很多事情。您不能返回其他类型。您不能返回null。您基本上可以抛出异常，返回损坏的对象（不良的构造函数），或（最佳情况）用合理的默认值替换某些内部零件。使用构造函数很麻烦，因为这样会抛出您的实例化（以及所有派生类型的实例化！）。然后，您将无法在成员初始化程序中使用它们。您最终会使用异常的逻辑来查看“我的创建成功了吗？”，这超出了由各处try / catch引起的可读性（和脆弱性）。

如果您的构造函数正在执行不重要的事情，或者可以合理预期失败的事情，请考虑使用静态Create方法（使用非公共构造函数）。它具有更多的可用性，更易于调试，并且在成功时仍可以为您提供完整的实例。

构造函数-方法复杂度的平衡确实是关于良好阶梯讨论的问题。通常使用空的构造函数Class() {}，以及Init(..) {..}用于更复杂事物的方法。在要考虑的参数中：

• 类序列化的可能性
• 使用与构造函数分离的Init方法，您经常需要Class x = new Class(); x.Init(..);多次重复同一序列，部分是在单元测试中。但是，效果不太好，无法清晰阅读。有时，我只是将它们放在一行代码中。
• 当单元测试的目标只是类初始化测试时，最好具有自己的Init，并通过中间的Asserts来逐个完成更复杂的动作。