依赖注入是否意味着没有内联初始化？

-1

如果我遵循类设计的依赖注入原则，我应该确保我的类不尝试在我的类中实例化它的依赖关系，而是通过构造函数询问对象。依赖注入是否意味着没有内联初始化？

这样，我在我的类提供，而单元测试它依赖的控制。这我明白。

但我不是肯定的是，这是否意味着随后依赖注入原理的好一流的设计意味着它的领域不应该被初始化内联？我们应该完全避免内联初始化来生成可测试代码吗？

编辑

哪个更好1或2？

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

public class Car { 

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

2017-09-30 DesirePRG

这显然取决于类型的字段。当你只需要在类中使用“基本”类型时，如“Number”，日期相关（java.time）类或例如“StringBuilder”是没有意义的。 – Tom

“内联初始化”是什么意思？这些字段是由类本身在构造函数中初始化的还是什么？ – lexicore

*我应该确保我的类不尝试在我的类中实例化其依赖关系*：绝对如此。不过，这正是你的第一个片段。所以你有你的答案。依赖性必须从课堂外提供。这显然不是你的第一个片段的情况。 –

在我看来，一般情况下，如果你认为该数据字段是一个依赖，然后让依赖管理容器应该管理。什么是依赖关系，什么是不依赖关系是一个棘手的问题，只有你可以做出决定。

例如：如果你的车的设计允许不同类型轮胎的工作，那么它是一个依赖。否则，在班车内部，你必须使用某种TyreFactory，这并不合理。

如果你用DI容器中工作，测试的类将是一件轻而易举的事。你将不得不为课堂提供一个存根/模拟，这显然是一个真正的好处。那么，在你的例子中，如果你采用第一种解决方案，那么你将如何测试你的车适用于不同类型的轮胎？

2017-10-01 05:42:29

不，这当然并不意味着内联初始化。我不是Java用户，但是这个术语与许多编程语言有关。

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

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

“依赖注入”是5美分概念的25美元的任期。 [...] 依赖注入意味着给对象实例变量。 [...]。

依赖注入基本上提供了一个对象需要的对象（它的依赖），而不是让它自己构造它们。这是一种非常有用的测试技术，因为它允许依赖性被嘲弄或剔除。

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

2017-10-01 05:54:28

回答