我多次听说使用依赖注入 (DI) 的好处是它允许/鼓励/强制执行单一职责原则 (SRP)。我怀疑这是否属实，并希望得到澄清，但我尚未找到。
在我看来，“依赖项的使用”允许 SRP，但是这些依赖项的创建方式（无论是通过实例化、注入还是其他机制）对 SRP 没有任何直接作用。有人可以提供一个示例，说明如何通过构造函数或属性使用 DI 来允许/鼓励/强制 SRP ，以便具有在类型初始值设定项或构造函数中创建的相同依赖项吗？
在第 2.1.3 节中，我们描述了 SRP 如何规定每个类都应该有一个更改理由。违反这一原则会导致类变得更加复杂并且更难以测试和维护。然而，通常情况下，查看一个类是否有多种更改原因可能具有挑战性。在这方面可以有所帮助的是从凝聚力的角度来看待 SRP。内聚被定义为类或模块元素的功能相关性。相关性越低，内聚性越低；内聚力越低，类违反 SRP 的可能性就越大。在 10.3 节中，我们将通过一个具体的例子来讨论内聚性。
坚持起来可能很困难，但如果您练习 DI，构造函数注入的众多好处之一就是，当您违反 SRP 时，它会变得更加明显。
（第 10.2.1 节）
几年前，我和我的一位客户一起遇到了一个包含 90 多个依赖项的类。这些都作为抽象注入到构造函数中，因此实践了依赖注入。然而，由于有超过 90 个依赖项，很难说这样的类“没有”违反 SRP，而且该类绝对违反了 SRP。
尽管开发人员使用了 DI，他们仍然能够创建一个严重违反 SRP 的怪物类。这基本上证明了你的观点：DI 不会强制执行，也不会自动导致 SRP。但是，另一方面，正如书中所述，具有许多构造函数参数的类很好地表明违反了 SRP。 DI 确实使 SRP 违规变得更加明显。在本书中，我们使用 4 或 5 个依赖项的启发式方法。有一个类比这个数字多，是时候仔细看看该类并检查它是否违反了 SRP（或任何其他 SOLID）原则。