构造函数注入:有多少依赖项太多了？

Question

我现在一直在使用手动构造函数注入DI.我注意到的一件事是我的构造函数开始变得相当长.

我有一个类依赖于一堆小物体 - 有时候在6到10之间.随着我继续将我的应用程序分解为更小的块,我可以看到这个数字随着时间的推移而增加.这是个常见的问题吗？

显然,这将取决于该项目.但是,基本问题是:

你什么时候开始对一个类的依赖数量感到不舒服？您使用哪些策略来减少这些依赖性？

Answer 1

这可能表明具有6-10个依赖关系的类本身需要重构.

Answer 2

我不担心.

相反,我担心课程太复杂了.

一个具有许多依赖项的类,它们使用它们但没有循环或if语句很好.在我最近工作的一些代码中,一个类中有大约14个依赖项.但是,只有一条路径通过代码,没有逻辑方法将依赖项分组到更好的类中.

应简化包含许多分支语句或复杂循环条件的具有少量依赖关系的类.

Answer 3

我认为不会超过三四个.如果你得到的不止这些,我会开始思考你是如何抽象出你的担忧的.例如,单个存储库对象应该满足相关类中的所有数据检索需求.

Answer 4

具有 6-10 个依赖项的类是一种代码味道。这表明该类可能违反了单一职责原则。

您使用哪些策略来减少这些依赖性？

Mark Seemann 在他的《重构聚合服务》一文以及他的《.NET 中的依赖注入》一书中明确了这一任务。您的类具有如此多的依赖项这一事实表明该类中存在多个职责。通常有一个隐含的领域概念等待通过识别它并将其纳入自己的服务来使其显式化。一般来说，大多数类永远不会需要超过 4-5 个依赖项。