为什么在构造函数中创建依赖项是个坏主意？

【问题标题】：Why is creating a dependency inside the constructor a bad idea?为什么在构造函数中创建依赖项是个坏主意？
【发布时间】：2022-01-17 06:30:09
【问题描述】：

我很难理解为什么违反规则是不好的））

   import {DepClass} from './di-import' // <- some dependency imports here

   class DI1 {
     dep1: DepClass
     constructor(){
       this.dep1 = new DepClass() // <- bad
     }
     ...... 
     }

    class DI2 {
      dep2: DepClass
      constructor(d: DepClass){     // <- slightly better
        this.dep2 = d
      }
      ......
    }

所以，我知道，该类不应该自己创建其依赖项的实例，IoC 规则中断。但到底发生了什么可怕的事情？开销会发生什么？

“内联”在构造函数中创建依赖项实例和将现有依赖项的副本作为参数传递给构造函数之间的工作区别是什么？除了两个类都工作正常之外））

想一想。也许，所有这些只是 DI 容器正常工作所需要的，它会仔细查看构造函数参数。

提前致谢

【问题讨论】：

标签： typescript dependency-injection

【解决方案1】：

constructor(){
  this.dep1 = new DepClass() // <- bad
}

在这里，当您创建依赖类的实例时，您将创建 DepClass 的新实例。

constructor(d: DepClass){     // <- slightly better
  this.dep2 = d
}

在这里，依赖注入框架为您实例化一个DepClass，并将其提供给任何想要访问该实例的类。

如果许多类依赖于DepClass，那么在第一个示例中，您将获得该类的许多实例，这些实例是在这些对象的构造过程中专门创建的。

在第二个示例中，只创建了一个 DepClass 实例，并且在构造后与任何声明它为依赖项的类共享。

对于像这样的人为的小例子，依赖注入看起来不是一个好主意。但是随着您的应用程序规模扩大，并且您有几十个类，每个类都有许多依赖项，保持这个干净就开始变得非常有用。

【讨论】：