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

Question

这是this SO post的改写。

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

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

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

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

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

Answer 1

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

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

改善“依赖过多”的情况

This blog post 谈到了这个确切的问题并用一个例子来支持它。

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

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