4

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

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

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

4

5 回答 5

6

在阅读这个问题之前，我没有想到类复杂性和 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 个参数）（大部分）设计简单，易于理解，并符合单一职责原则。

于 2008-09-26T21:47:50.647 回答
2

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

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

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

于 2008-09-23T19:10:17.410 回答
1

乔治，

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

很多“ISA”关系？很多“hasa”关系？

粉丝多吗？还是扇出？

乔治的回应：“一直以来，一直在尝试遵循组合而不是继承建议……但这有什么关系呢？”

因为它主要是“hasa”，所以你应该没事。

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

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

于 2008-09-23T19:01:03.907 回答
1

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

于 2008-09-23T19:10:31.217 回答
0

这一切都取决于您用来执行 IOC 的容器类型以及容器采用什么方法，是否使用注释或配置文件来使要实例化的对象饱和。此外，如果您的构造函数参数只是简单的原始数据类型，那么这并不是什么大问题；但是，如果您有非原始类型，那么在我看来，您可以使用基于属性的 DI 而不是基于构造函数的 DI。

于 2008-12-31T21:16:46.850 回答