混合基于构造函数和基于 setter 的注入是一件坏事吗？

Question

我有一个从 CSV 文件操作导入产品的类，它需要大约 7 个参数。这是进口商绝对需要的信息。

所有这些参数都有相同的生命周期。最后我们必须有一个Immutable Object。

我太害怕在构造函数中列出所有这些，因为它会影响可读性，并决定将其中的 3 个移到 setter 注入中。但显然这不是一个优雅的解决方案。

问题：

1) 混合使用基于构造函数和基于 setter 的注入是一种不好的做法吗？

2) 如何解决这个特定问题？

我在考虑应用 Martin Fowler 的“Introduce Parameter Object”重构，但这样做有问题。

4 参数可以很容易地移动到 Parameter 对象（customerId、projectId、languageId 等） - 所有整数。

其他 3 个参数是我注入的对象（模拟单元测试需要它）。

Answer 1

将构造函数注入和属性注入混合起来不一定是坏事，但它可能并不常见。作为一个整体策略，请避免属性注入，因为它更难以正确实施（这听起来可能违反直觉，但确实如此）。

了解何时使用每种模式很重要。

• 构造函数注入应该是您的默认注入模式。它非常容易实现，并且可以保证不变量：将其分配给只读字段以确保消费者的不变量。
• 当您拥有良好的本地默认实现，但您希望遵循Open/Closed Principle 并允许高级用户通过提供替代实现来扩展类时，可以使用属性注入。

你不应该因为构造函数化妆品而应用属性注入。

当您需要太多依赖项时，这表明您可能违反了Single Responsibility Principle - 该类只是试图一次做太多事情。

与其引入参数对象（否则是一个好建议），更好的选择是将两个或多个依赖项封装到一个聚合服务中，以协调这些依赖项的交互。

想象一下您的初始构造函数如下所示：

public MyClass(IDep1 dep1, IDep2 dep2, IDep3 dep3, IDep4 dep4, IDep5 dep5)

经过一些分析，您会发现在这种情况下 IDep1、IDep3 和 IDep4 将以特定方式一起使用。这将允许您引入一个像这样封装这些的聚合服务：

public class AggService : IAggService
{
    public AggService(IDep1 dep1, IDep3 dep3, IDep4 dep4)
    {
        // ...
    }

    // ...
}

您现在可以将原来的构造函数改写成这样：

public MyClass(IAggService aggSrvc, IDep2 dep2, IDep5 dep5)

等等……

很常见的是，聚合服务本身就是一个合适的概念，突然之间，您拥有比刚开始时更丰富的 API。