依赖注入-注入参数的数目

Question

今晚，我在思考它所讲述的关于具有许多注入对象的类的设计和体系结构的内容。我特别考虑了setter和构造函数注入。

Setter注入支持者总是使用构造函数注入复杂性的论点来反对setter简单性，特别是在构造函数中的参数数量增加的情况下，但这是一个不同的主题。

我认为，大量注入的部分表明违反了该物体的单一责任。可能会有特殊的雪花，但总的来说，我认为是个好指标。

现在，如何对抗它，尤其是在构造函数的垂直深度大于3的情况下？

我在考虑一些指导\规则来对付这些案子。

说明:垂直深度

假设我们有一些复杂的体系结构，其中一些类UniversalHelper/IUniversalHelper是在根中或根附近创建的，并且实例在整个图中渗透得越来越深。我不认为记录器是这样的对象，它们确实具有特定的用途，必须渗透到整个体系结构中，而是某种类似于通用数据访问的东西。它认为应该使用类似于特定数据访问用例的特定数据管理器，然后更一般的对象UniversalHelper不会渗透到体系结构中，它的垂直深度将是有限的，而水平深度将在一个特定的点上增长，其中UniversalHelper将用于创建特定的数据管理器，对象对单个责任目标的责任将更精确、更受限或有限。

显然，允许一个宇宙物体进入整个建筑的地方，迟早会有2，3，5 :)。这是合乎逻辑的，因为对于在给定项目中经验丰富的开发人员来说，这是一种有用的、正确的和经过测试的生活方式，对于加入特定项目的新开发人员来说，这是一个标志，它总是这样做的，如果您以同样的方式这样做，那么通过项目中经验丰富的同事进行代码评审的可能性更高……

Answer 1

原则上，您可以通过两种方式进行依赖注入:通过将所有注入的类传递给创建实例的构造函数，或者拥有一些全局方法，该方法提供可以向任何需要的人注入的所有类。(我肯定有人能找到第三条路:-)

后一种方法意味着一个实例只需要获取它需要自己并因此知道的那些注入的类。

第一个方法的问题是，如果实例有依赖项(如果它创建了其他实例)，那么它必须将正确的注入类传递给这些实例的构造函数。这些可能是实例不关心、也不应该关心的注射。

最坏的情况是:将一个类I注入到一个A类的实例中。因此，任何创建A实例的构造函数都需要传递注入I。因此，所有创建A类实例的类B都需要I，所以所有类C的实例创建B实例都需要I，依此类推。

这就是为什么我非常喜欢“每个人都适合自己”的原因:任何需要注射的例子都应该从某个地方得到。