如果您使用Inversion of Control，构造函数的大小是否重要？

Question

所以我有10个对象，每个对象都有1-3个依赖项（我认为就松散耦合而言是可行的），还有一些可用于定义行为的设置（超时，窗口大小，等）。

在我开始使用Inversion of Control容器之前，我会为每个需要多于1个设置的对象创建一个工厂甚至是一个简单的ObjectSettings对象，以使构造函数的大小保持在建议的“小于4“参数大小。我现在正在使用控制容器的反转，我只是没有看到它的重点。当然，我可能会得到一个带有7个参数的构造函数，但是谁在乎呢？无论如何，它都被IoC填写。

我在这里遗漏了什么或这基本上是正确的吗？

Answer 1

在阅读这个问题之前，我没有想到类复杂性和IoC构造函数的大小之间的关系，但我的分析表明，在IoC构造函数中有很多参数是code smell要注意的时候使用IoC。有一个目标是坚持一个简短的构造函数参数列表将帮助您保持类本身简单。 single responsibility principle之后将引导您实现此目标。

我在一个系统上工作，该系统目前有122个使用Spring.NET框架实例化的类。这些类之间的所有关系都在它们的构造函数中设置。不可否认，在我违反一些规则的情况下，该系统的公平份额不是完美的代码。 （但是，嘿，我们的失败是学习的机会！）

这些类的构造函数有不同数量的参数，我在下表中显示。

Number of constructor arguments    Number of classes
           0                             57
           1                             19
           2                             25
           3                              9
           4                              3
           5                              1
           6                              3
           7                              2
           8                              2

零参数的类可以是具体的策略类，也可以是通过向外部系统发送数据来响应事件的类。

那些有5或6个参数的人都有点不优雅，可以使用一些重构来简化它们。

具有7或8个参数的四个类是God objects的优秀示例。它们应该被分解，并且每个都已经在我的系统中的故障列表中。

其余的类（1到4个参数）（大多数）设计简单，易于理解，并符合single responsibility principle。

Answer 2

对许多依赖项（可能超过8项）的需求可能表明存在设计缺陷，但总的来说，只要设计具有凝聚力，我认为没有问题。

此外，请考虑使用服务定位器或静态网关来解决基础结构问题，例如日志记录和授权，而不是混淆构造函数参数。

编辑：8可能太多了，但我觉得它有奇怪的情况。在看了李的帖子后我同意，1-4通常是好的。

Answer 3

G'day George，

首先，对象之间有什么依赖关系？

很多“isa”关系？很多“哈萨”的关系？

很多粉丝？或扇出？

乔治的回答：“大多数人都试图遵循继承建议的构成......但为什么会这么重要呢？”

因为它主要是“哈萨”你应该没事。

最好确保正确完成组件的构造（和销毁），以防止内存泄漏。

而且，如果这是在C ++中，请确保使用虚拟析构函数？

Answer 4

这是一个艰难的问题，为什么我喜欢混合方法，其中适当的属性是可变的，只有不可变属性和没有有用默认值的必需依赖项是构造函数的一部分。有些课程是用必需品构建的，然后在必要时通过设置器进行调整。

Answer 5

这一切都取决于您用来做IOC的容器类型以及容器采用什么方法，无论它是使用注释还是配置文件来使对象充满信息。此外，如果你的构造函数参数只是简单的原始数据类型，那么它并不是一个大问题;但是，如果您有非原始类型，那么在我看来，您可以使用基于属性的DI而不是基于构造函数的DI。