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

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

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

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

在阅读这个问题之前,我没有想到类复杂性和IoC构造函数的大小之间的关系,但我的分析表明,在IoC构造函数中有许多参数是使用IoC时要注意的代码味道.有一个目标是坚持一个简短的构造函数参数列表将帮助您保持类本身简单.遵循单一责任原则将指导您实现这一目标.

我在一个系统上工作,该系统目前有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个参数的四个类是上帝对象的极好例子.它们应该被分解,并且每个都已经在我的系统中的故障点列表中.

其余的类(1到4个参数)(大多数)设计简单,易于理解,并符合单一责任原则.