在构造函数中应该做多少工作

Question

这是一个理论问题，我想我正在用它来找到解决这个问题的标准程序。

如果我有一个构造器方法，它做了大量的设置操作来收集数据等等，我是应该在构造器中保留“所有的构造”，还是应该尝试从构造器内部调用其他方法(因为代码看起来基本上是这样的)，或者我应该只初始化我必须要做的所有事情，并将其他事情留到以后处理，如果它们确实需要的话？

下面是一个例子。

我创建的对象基本上就是一个集合管理器。它需要从文件中读取数据，并将其存储在数组中。

我是只使用构造函数来创建一个具有基本属性的对象并在以后读取数据，还是应该读取所有信息并在构造函数中设置数组，这样可以节省时间，但在这里会占用额外的时间，还是应该像下面这样做

 public myConstructor(String filename) {
data = readDataIn(filename);
} 

这不是实际的代码，只是外包给不同的方法来“美化代码”的一个例子，而不是一个超长的构造函数方法我可以说有5-6个短小美观的方法只能由构造函数访问。

Answer 1

构造函数应该做足够的工作来使实例进入满足其约定的状态。然后，每个方法都应该做足够的工作来满足方法的约定，并使实例处于满足其约定的状态。

构造函数调用很少会引起副作用或修改其输入。这些通常不是满足合同所必需的。例如，connection类不应该在构造时接触网络。因为它必须是可关闭的，所以closed状态必须是其契约的一部分，因此“刚好足够的工作”标准规定构造器将其置于就绪状态，但尚未打开状态。

您的特定示例将您的类耦合到文件系统。通过使用Guava Files进行读取并获取一个包含内容的字符串，您可能会得到一个更易测试、更通用的类。您可以通过编写一个方便的执行new MyClass的static MyClass fromFile(String path)工厂函数来获得耦合到文件系统的构造函数的便利性。这会将耦合到文件系统的代码部分移出与实例变量交互的部分，从而减少了需要测试的可能交互的数量。正如其他人所指出的，依赖注入是实现解耦的另一种好方法。

Answer 2

这取决于你的API风格。请注意，您可能希望有多个构造函数，例如：

public MyThing(String filename) { }
public MyThing(FileInputStream filestream) {}
public MyThing(File file) { }
public MyThing(byte[] rawdata) { }

在这种情况下，明智的做法是将文件加载操作合并为一种或两种方法(文件打开和文件解析)

Answer 3

在这种情况下，我将使用依赖注入，以便您的构造函数需要已经计算的数据，并将计算推迟到调用构造函数的任何地方。我可能会提供一个额外的静态工厂函数来完成所有这些复杂的设置，这样就可以方便地构造这个对象(例如在测试中)，但至少这个类的用户可以想出一个更聪明的(可能是并行化的或者延迟初始化的)创建这个类的方法。