如何减少控制器和业务层服务中构造函数参数的数量？

Question

这是这篇 SO 帖子的重新措辞。

我发现使用中介模式可以有效减少控制器中的参数数量。

然后我开始怀疑这是否是情感领域服务。

但这不会隐藏服务的依赖关系吗？

我记得在某处读到，如果我注入了一堆依赖项，我可能有一个更大的域概念，可以封装在它自己的服务中。我发现这是一种有效的模式。

那么，如何减少业务层服务中构造函数参数的数量呢？

Answer 1

太多的构造函数参数会产生代码异味，通常表明违反了单一职责原则- 因此您需要注意 SOLID 代码库中的“S”。

构造函数参数是一个依赖项。通过使用调解器“解决”问题，您仍然拥有相同数量的依赖项，只是构造函数参数更少。您本质上是从可见的 SRP 代码气味转向隐藏的 SRP 代码气味 - 这并不是真正的进步。

改善“太多依赖”的情况

这篇博文讨论了这个确切的问题，并用一个例子来支持它。

改善情况的基本方法是找到围绕一组依赖项聚集的代码，并将该代码提取到新的服务类中：

1. 分析依赖关系如何相互作用以识别行为集群。
2. 从这些簇中提取一个接口。
3. 将原始实现复制到实现新接口的类。
4. 将新接口注入消费者。
5. 用调用新的依赖项替换原始实现。
6. 删除多余的依赖项。