Angular.js - Javascript 依赖注入

Question

我读到了DI 和DI in Angular.js。

据我了解，Angular.js 中的 DI 意味着 Angular.js 允许控制器、工厂、服务或其他人指定依赖项，而无需创建依赖项。

问题：

1. 在某些时候必须创建依赖项，使得创建依赖项的地方没有被 DIed，我怎么理解这个？

2. 如果我有怎么办：

   var thing = function(dep){
     this.dep = dep || new depCreator();
   }
   

   这是死了吗？还是取决于 dep 是否传递给函数？

3. 据我所知，DI 意味着允许设置依赖项，无论是在函数还是对象中，最后，是否意味着将初始化/配置/数据与程序的其他部分分开（逻辑？虽然我们可以也有初始化逻辑）？：

   var dep1 = 'qwe';
   var thing = function(dep){ this.dep = dep; }
   var diedThing = new thing(dep1);
   

   例如，这将允许在配置文件中设置dep1。

4. 如果实现 DI 的纯 JavaScript 是：

   var thing = function(dep){
     this.dep = dep;
   }
   

   而不是

   var thing = function(){
     this.dep = new depCreator();
   }
   

   这样对吗？

   但是如果 depCreator 依赖于配置文件（或提取的配置），这会被 DI 吗？

5. 当我读到 Angular.js 有（？）DI 时，认为这个 DI 意味着 Angular.js 为我创建和搜索依赖项是否正确？还有什么意思吗？

6. 最后，如果 DI 这么复杂，只是意味着将配置与实现（或逻辑？）分开，为什么不称其为单一职责原则，即方法做什么方法做什么，配置做什么配置，等等。

最后，DI对我来说是一个主观的概念，你是如何想象和在一些应用中划分职责的，这是否接近正确？

抱歉问题太长了。

Answer 1

1. 创建依赖的地方不依赖它。它的唯一目的通常是创建“事物”并将其注册到 DI 子系统。这没有什么奇怪或可疑的。

2. 您为什么要这样做？如果您需要更大的灵活性，也许可以改为依赖为您创建对象的服务。

3. DI 意味着依赖注入 - 正是如此，您不会创建依赖于自己的东西。相反，您要求它，瞧，它可供您使用。您无需知道如何创建它、创建它的人等。

4. 如果 depCreator 依赖于配置文件，那很好。它可以使用它们。在向 DI 子系统注册 dep 之前，它几乎可以做任何事情。这就是您要做的，创建一个服务/工厂 depCreator 来注册 dep 并使其可用于您应用的其他组件。

5. 没有问号。 Angular有一个 DI 子系统，它实际上是 Angular 背后的核心思想之一。 Angular 为您提供了许多开箱即用的组件，可以随时注入，其余的您必须自己创建和注册。

6. 我不知道我是否会说 DI 很复杂。也许实现起来很棘手，我不知道，但是一旦你学会使用它，你就不想回去了。角度的 DI 可能是我见过的最容易使用的。太好了，有点透明。过了一会儿，您甚至都没有注意到它的存在，而且它非常工作得很好。

我认为你的最后一句话是正确的。就我看来，这是一种关注点分离的方式。但是有很多很多很好的资源可以解释 DI，所以我不会在这里详细说明。与往常一样，我建议您阅读 ng-book 以了解更多关于角度的具体细节。