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

Question

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

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

显然，这将取决于该项目。但是，基本问题是：

您何时开始对某个类的依赖项数量感到不安？您使用哪些策略来减少这些依赖关系？

Answer 1

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

Answer 2

我不担心。

相反，我担心课程太复杂了。

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

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

Answer 3

我认为不会超过三四个。如果你得到的不止这些，我会开始思考你是如何抽象出你的concerns。例如，单个repository对象应满足相关类中的所有数据检索需求。

Answer 4

Runcible，

这是Castle Windsor项目的链接。它是一个Inversion of Control容器。这些容器允许工厂类一起收集依赖项，并将它们作为单个对象注入到构造函数中。

http://www.castleproject.org/container/index.html

我听说过温莎的好消息。 Spring也创建了一个IoC容器，there are others。

Answer 5

具有6-10个依赖项的类是代码气味。这表明该课程可能违反Single Responsibility Principle。

  

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

马克·西曼（Mark Seemann）在他的文章Refactoring to Aggregate Services中更明确地完成了这项任务，而且在他的书Dependency Injection in .NET中也是如此。您的类具有如此多的依赖关系，这表明该类中有多个职责。通常会有一个隐式域概念等待显式通过识别它并使其成为自己的服务。一般来说，大多数类应该永远不需要超过4-5个依赖项。

Answer 6

您可能还想查看构造函数的任何参数是否也应该合并为一个类（假设参数作为类有意义）。

您可能还希望查看某些依赖项的ServiceLocator模式。如果您必须将依赖项传递给一长串构造函数，那么尤其如此。