依赖注入框架-依赖传播

Question

我了解什么是依赖注入，但是就其如何给消费者带来好处而言，我仍然没有看到完整的画面。 请参见下面的示例。

//bad
class car () {
  var tire = new Tire('snow');
}

//good
class car () {
  var tire;
  constructor(tire){
    this.tire=tire
  }
}

因此，我阅读的大多数文章都指出，上面的示例很好，因为它消除了汽车对轮胎的依赖性，因此更具可测试性。 但是另一个实例化汽车对象的类呢？ 如果driver要召唤car课，那将不会迫使驾驶员实例化car对象和tires 。 似乎依赖性总是总是进一步传播。 这在哪里结束？ 实际实例化对象的是什么？ 这就是DI框架的全部内容吗？

Answer 1

您的依赖性要求一直都“传播”是正确的。 希望实例化其汽车的驾驶员需要携带Car和Tire 。 具有许多驾驶员的驾驶员池将需要携带Driver ， Car和Tire等等。 一种简单的解决方法是将东西捆绑到工厂中：

class Driver {
    constructor(carFactory) {
        this.car = carFactory.newCarWithRegularTires();
    }
}

_{（仅出于说明目的，请参阅下文。）}

你可以注入不同的工厂，可以创建其他的车，和的依赖Car可以更改，恕不Driver需要要注意的任何现象。

更进一步，您可以创建一个通用的全局工厂，该工厂可以创建各种对象并知道如何满足每个对象的依赖关系，这是一个依赖关系注入容器。 通常，您以文本格式配置它们，从而声明Car需要Tire ，并且在向其请求Car实例时，它知道首先实例化Tire并将其传递。

DI容器的缺点在于，尽管您仍然可以通过重新配置DI容器简单地交换依赖关系，但这有时意味着您必须重新配置整个事物，它变成了一个庞大的相互依赖的对象注册表。 您应该避免创建一个巨大的über容器，而要保持模块化。

关于工厂的另一句话：上面的工厂示例不是很好。 如果对象需要在运行时创建对象的新实例，则应使用工厂。 它不应该用一个简单的工厂，以满足可能被直接注入的依赖。

最后，您希望在类的声明和直接接收依赖之间取得平衡，但又不要创建非常深的依赖层次。 使依赖关系尽可能浅是一个好的开始，在状态点引入工厂或模块化DI容器是另一种方法。