我意识到这个问题已被多次询问，但我想在一个我正在这里工作的特定例子中构建它。我正在研究一种在网格上运行的有限元代码。网格在逻辑上是一个对象，在它被“构造”或构建之前，它不能对它做任何事情。似乎有意义，然后将网格参数传递给构造函数并让构造函数构建网格。在网上搜索，我看到一般意见认为这不是一个好主意，构造函数应尽可能少。
网格生成可能是一个漫长而复杂的过程。另一方面，网格在生成之前是完全不可用的，我会考虑它的构造。我可以将每个步骤映射为我希望客户端调用的方法，但这些方法将始终相同，并且它们将始终使用相同的参数。即使内部变化，公共接口也会极其不可能。此外，客户端不应该关注网格生成细节可能是有道理的。考虑到这一点，在构造函数中完全生成网格并在之后处于准备使用状态似乎是有意义的。我还可以创建一个对客户端不透明的简单生成方法，但是为什么构造函数不能做同样的事情呢？它必须是可用的。
在将这些内容放入构造函数中时，我是否应该注意隐藏的危险？
答案 0 :(得分：1)
你没有提到的另一种可能性是懒洋洋地执行昂贵的操作，即第一次需要它的结果。
这样可以保持对象构造的便宜，不会给客户端带来额外的调用方法负担，并且如果从不使用对象，则完全避免了昂贵的操作。
主要缺点是复杂性略有增加，特别是在多线程环境中。
答案 1 :(得分：1)
构造函数需要构建之后将在您的方法中使用的“基本”构建块或元素。如果大多数方法都在网格上工作，我会使用构造函数来生成网格。另一方面，如果大多数方法可以在比网格更小的元素上工作，那么也许你不应该将它包装在构造函数下。