inversion-of-control - 如果您使用控制反转，构造函数的大小是否重要？

Question

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

现在，在我开始使用控制反转容器之前，我会为每个需要 1 个以上设置的对象创建一个工厂，甚至可能创建一个简单的 ObjectSettings 对象，以将构造函数的大小保持在推荐的“小于 4”参数尺寸。我现在正在使用控制容器的反转，但我看不到它的全部意义。当然我可能会得到一个带有 7 个参数的构造函数，但谁在乎呢？无论如何，这一切都由国际奥委会填写。

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

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 的极好例子。 .他们应该被拆散，而且每一个都已经在我的系统故障点 list 上。

其余的类(1 到 4 个参数)(大部分)设计简单，易于理解，并符合 single responsibility principle .