因此，我大概有10个对象，每个对象具有1-3个依赖关系(就松散耦合而言，我认为可以)，还有一些可用于定义行为的设置(超时，窗口大小等)。

现在，在我开始使用Inversion of Control容器之前，我将为每个需要多个设置以将构造函数的大小保持为建议的"小于4"参数的对象创建一个工厂，甚至可能创建一个简单的ObjectSettings对象尺寸。我现在使用的是控制容器的倒置，但是我对它没有多大的了解。当然可以得到带有7个参数的构造函数，但是谁在乎呢？无论如何，这些都是由IoC填写的。

我在这里错过了什么吗，或者这基本上是正确的吗？

解决方案

乔治(G'day George)，

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

很多" ISA"关系？很多"有"关系？

大量扇入吗？还是扇出？

乔治的回应："大多数情况下，人们一直试图遵循继承建议的组成……为什么这很重要？"

因为它主要是" hasa"，所以我们应该没事。

尽管可以防止内存泄漏，但最好确保正确完成了组件的构造(和销毁)。

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

需要许多依赖关系(可能超过8个)可能表明存在设计缺陷，但总的来说，我认为只要设计具有凝聚力就没有问题。

另外，考虑将服务定位器或者静态网关用于基础结构方面的问题，例如日志记录和授权，而不要弄乱构造函数的参数。

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

这是一项艰巨的任务，为什么我赞成使用一种混合方法，在该方法中，适当的属性是可变的，并且只有不可变的属性和所需的依赖项(没有有用的默认值)才是构造函数的一部分。有些类是使用基本要素构建的，然后根据需要通过设置器进行调整。

在阅读此问题之前，我还没有想到类的复杂性与IoC构造函数的大小之间的关系，但是我的以下分析表明，在使用IoC时要注意的一点是，在IoC构造函数中包含许多参数。目标是坚持简短的构造函数参数列表，这将使类本身保持简单。遵循单一责任原则将引导我们朝着这个目标迈进。

我在一个当前有使用Spring.NET框架实例化的122个类的系统上工作。这些类之间的所有关系都在其构造函数中设置。诚然，在我违反了一些规则的情况下，该系统有相当一部分不是完美的代码。 (但是，嘿，我们的失败是学习的机会！)

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

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个论点的四个类别是上帝对象的极好例子。应该将它们分解，并且每个都已经在我系统内的故障点列表中。

其余的类(1到4个自变量)(大多数)经过简单设计，易于理解并符合单一职责原则。

这完全取决于我们用来执行IOC的容器类型，以及容器是否使用注释或者配置文件使要实例化的对象饱和，采用哪种方法。此外，如果构造函数参数只是普通的原始数据类型，那么这没什么大不了的。但是，如果我们有非基本类型，那么在我看来，我们可以使用基于属性的DI而不是基于构造器的DI。