共计 1157 个字符，预计需要花费 3 分钟才能阅读完成。
每个基于 Java 的应用程序都有一些对象，它们协同工作以出现最终用户所看到的工作应用程序。在编写简单的 Java 应用程序时，应用程序类应尽可能独立于其余 Java 类，以减少重用这些类的可能性，并在单元测试时独立于其余类进行测试。依赖注入（或有时称为连贯）有助于将这些类粘合在一起，同时放弃它们的独立性。
假如您有一个具备文本编辑器组件的应用程序，并且您想要提供拼写查看。你的规范代码看起来像这样 –
public class TextEditor {
private SpellChecker spellChecker;
public TextEditor() {
spellChecker = new SpellChecker();}
}
咱们在这里所做的是，在 TextEditor 和 SpellChecker 之间创立一个依赖项。在管制反转的状况下，咱们会做这样的事件 –
public class TextEditor {
private SpellChecker spellChecker;
public TextEditor(SpellChecker spellChecker) {
this.spellChecker = spellChecker;}
}
在这里，TextEditor 不应该放心 SpellChecker 的实现。SpellChecker 将独立实现，并在 TextEditor 实例化时提供给 TextEditor。整个过程由 Spring 框架管制。
在这里，咱们从 TextEditor 中删除了齐全控制权并将其保留在其余中央（即 XML 配置文件），并且依赖项（即类 SpellChecker）通过 Class Constructor 注入到类 TextEditor 中。因而，控制流已被依赖注入（DI）“反转”，因为您曾经无效地将依赖委托给了某个内部零碎。
注入依赖项的第二种办法是通过 TextEditor 类的 Setter 办法，咱们将在其中创立 SpellChecker 实例。此实例将用于调用 setter 办法来初始化 TextEditor 的属性。
因而，DI 存在于两个次要变体中，以下两个子章节将通过示例涵盖它们 –
不。依赖注入类型和形容
1 基于构造函数的依赖注入
当容器调用带有多个参数的类构造函数时，基于构造函数的 DI 就实现了，每个参数代表对另一个类的依赖。
2 基于 Setter 的依赖注入
基于 Setter 的 DI 是通过容器在调用无参数构造函数或无参数动态工厂办法来实例化 bean 后调用 bean 上的 setter 办法来实现的。
您能够混合应用基于 Constructor 和 Setter 的 DI，但应用结构函数参数作为强制依赖项和 setter 作为可选依赖项是一个很好的教训法令。
应用 DI 准则，代码更清晰，当对象提供依赖项时，解耦更无效。该对象不查找其依赖项，也不晓得依赖项的地位或类，而是由 Spring 框架解决所有事件。