13

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

所有这些参数都具有相同的寿命。最后我们必须有一个不可变对象。

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

问题：

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

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

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

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

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

4

1 回答 1

28

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

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

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

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

当您需要太多依赖项时，这表明您可能违反了单一职责原则——该类只是试图一次做太多事情。

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

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

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。

于 2009-12-31T15:25:12.537 回答