依賴注入框架-依賴傳播

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容器是另一種方法。