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

Question

所以我可能有10个对象，每个对象都有1-3个依赖关系（就松散耦合而言，我认为没问题），但也有一些设置可以用来定义行为（超时，窗口大小等） ）。

现在在我开始使用Inversion of Control容器之前，我会创建一个工厂，甚至可能为每个对象创建一个简单的ObjectSettings对象，这需要超过1个设置才能将构造函数的大小保持为建议的“less比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

G'day George，

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

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

很多粉丝？或扇出？

乔治的回应：“一直以来，一直试图按照继承建议的构成......为什么它会影响到？”

由于它主要是“哈萨”，你应该没问题。

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

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

Answer 3

对许多依赖关系（可能超过8个）的需求可能表明设计缺陷，但总的来说，我认为只要设计具有内聚性就没有问题。

另外，考虑使用服务定位器或静态网关来解决诸如日志和授权等基础设施问题，而不是混淆构造函数参数。

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

Answer 4

这是一个棘手的问题，为什么我喜欢混合方法，其中适当的属性是可变的，只有不可变属性和所需的依赖项没有有用的默认值是构造函数的一部分。有些课程是根据要领构建的，如果需要的话可以通过制定者进行调整。

Answer 5

这一切都取决于您用于执行IOC的容器类型，以及容器使用注释或配置文件来饱和待被对象化的对象所采用的方法。而且，如果你的构造函数参数只是普通的原始数据类型，那么它并不是什么大不了的;然而，如果你有非原始类型，那么在我看来，你可以使用基于属性的DI而不是基于DI的构造器。