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

Question

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

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

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

问题:

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

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

我正在考虑应用 Martin Fowler 的“引入参数对象”重构，但这有一个问题。

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

其他 3 个参数是我注入(inject)的一个对象(模拟单元测试需要它)。

Answer 1

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

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

构造函数注入(inject)应该是您的默认注入(inject)模式。它 super 容易实现并且可以保证不变量:将其分配给只读字段以确保消费者的不变量。

有好的时候可以使用属性注入(inject)本地默认值 实现，但您想遵循 Open/Closed Principle并允许高级用户通过提供替代实现来扩展类。

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

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

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

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

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。