在构造器上做的很不好吗？(Is doing a lot in constructors bad? [closed])

在构造器上做的很不好吗？(Is doing a lot in constructors bad? [closed])

使所有领域都是final的一般是一个好主意，但有时我发现自己在构造函数中做了一切。 最近我结束了一个类，实际上在构造函数中的所有内容 ，包括读取属性文件和访问数据库。

一方面，这是类是什么，它封装了数据读取，我喜欢创建对象完全初始化。 构造函数根本不复杂，因为它代表了大部分的工作，所以看起来不错。

另一方面，感觉有点奇怪。 此外，在17:58左右的这个演讲中，建设者没有做太多工作的好理由。 我想我可以通过传递适当的虚拟作为构造函数来消除问题。

问题仍然存在：在构造函数中做了很多工作（甚至所有的工作）都不好吗？

Making all fields final is in general a good idea, but sometimes I find myself doing everything in the constructor. Recently I ended up with a class doing actually everything in the constructor, including reading a property file and accessing a database.

On one hand, this is what the class is for, it encapsulates the data read and I like creating objects completely initialized. The constructor is not complicated at all as it delegates most of the work, so it looks fine.

On the other hand, it feels a bit strange. Moreover, in this talk at about 17:58 there are good reasons for not doing much work in constructor. I think I can eliminate the problem by passing appropriate dummies as constructor arguments.

The question remains: Is doing a lot of work (or even all the work) in constructors bad?

最满意答案

我认为“在建设者工作”是可以的...

只要你不违反单一责任原则（SRP），并坚持使用依赖注入（DI） 。

最近我一直在问自己这个问题。 反对在我发现的构造函数中做工作的动机是：

这使得测试很难 我所看到的所有例子都是DI不被使用的地方。 这实际上并不是建设者在做实际工作的过错。 您可能不需要您的构造函数计算的所有结果，浪费处理时间，并且难以孤立测试。 这基本上是违反SRP的 ，而不是建设者在做每个工作的错误。 旧的编译器在构造函数中抛出异常时遇到麻烦，所以你不应该在构造函数中分配字段以外的任何东西。 我不认为编写新的代码来考虑历史的编译器缺陷是一个好主意。 我们也可以尽快取消C ++ 11，如果我们这样做，那么一切都很好。

我的意见是...

...如果您的构造函数需要努力遵守资源获取初始化（RAII） ，并且类不会违反SRP和DI被正确使用; 那么在构造函数中做工就是A-Okay！ 如果您想防止使用初始化失败的类对象，而不是依赖用户来检查某些返回值，您甚至可以抛出异常。

I think that "Doing work in the constructor" is okay...

... as long as you don't violate Single Responsibility Principle (SRP) and stick to using Dependency Injection (DI).

I have been asking myself this question too lately. And the motivation against doing work in the constructor that I have found are either:

It makes it hard to test All examples I have seen have been where DI wasn't used. It wasn't actually the fault of the constructor doing actual work. You might not need all the results that your constructor calculates, wasting processing time and it's hard to test in isolation. This is basically a violation of SRP, not a fault of the constructor doing work per say. Old compilers have/had trouble with exceptions thrown in constructors, hence you shouldn't do anything other than assign fields in constructors. I don't think it's a good idea to write new code taking historical compiler deficiencies into account. We might as well do away with C++11 and all that is good all together if we do.

My opinion is that...

... if your constructor needs to do work for it to adhere to Resource Acquisition Is Initialization (RAII) and the class does not violate SRP and DI is properly used; Then doing work in the constructor is A-Okay! You can even throw an exception if you'd like to prevent usage of a class object whose initialization failed completely instead of relying on the user to check some return value.