Question

如果我遵循类设计的依赖注入原则，我应该确保我的类不会尝试在我的类中实例化它的依赖项，而是通过构造函数请求对象。

通过这种方式，我可以控制我为类提供的依赖关系，同时对其进行单元测试。我明白了。

但是我不确定这是否意味着遵循依赖注入原则的良好类设计意味着它的字段永远不应该内联初始化？我们是否应该完全避免内联初始化以生成可测试代码？

修改

哪个更好1或2？

1

  public class Car {
       private Tire tire = new Tire(); // 
    }

2

public class Car {

   private Tire tire;
   public Car(Tire tire) {
       this.tire = tire
   }
}

Answer 1

在我看来，一般来说，如果您认为数据字段是依赖项，那么让依赖项管理容器应该对其进行管理。什么算依赖，什么不依赖是一个棘手的问题，只有你可以决定。

例如：如果你的汽车设计允许使用不同类型的轮胎，那么它就是一种依赖。否则，在Car类中你必须使用某种TyreFactory，这不太合理。

如果您使用DI容器，测试该类将是轻而易举的。你必须为班级提供一个存根/模拟，这显然是一个真正的好处。因此，在您的示例中，如果您使用第一个解决方案，那么您将如何测试您的汽车是否适用于不同类型的轮胎？

Answer 2

不，它肯定不意味着内联初始化。我不是Java用户，但这个术语与许多编程语言相关。

基本上，您不是让对象创建依赖项或要求工厂对象为它们创建一个依赖项，而是将所需的依赖项传递到外部对象中，并使其成为别人的问题。

public SomeClass() {
    myObject = Factory.getObject();
}

对于5美分概念，“依赖注入”是一个25美元的术语。 [...] 依赖注入意味着为对象提供实例变量。 [...]。

依赖注入基本上是提供对象所需的对象（它的依赖关系），而不是让它自己构造它们。它是一种非常有用的测试技术，因为它允许模拟或删除依赖项。

任何应用程序都由许多对象组成，这些对象相互协作以执行一些有用的东西。传统上，每个对象都负责获取它自己与它协作的依赖对象（依赖项）的引用。这导致高度耦合的类和难以测试的代码。