什么是依赖注入？

依赖注入（DI）意味着分离彼此依赖的对象。假设对象A依赖于对象B，因此想法是将这些对象彼此分离。我们不需要使用new关键字对对象进行硬编码，而是在运行时共享对对象的依赖关系，而不管编译时间如何。如果我们谈论

依赖注入在Spring中的工作原理：

我们不需要使用new关键字硬编码对象，而是在配置文件中定义bean依赖关系。弹簧容器将负责连接所有部件。

控制反转（IOC）

IOC是一个通用概念，可以用多种不同的方式表达，依赖注入是IOC的一个具体例子。

两种类型的依赖注入：

构造器注入沉淀剂注入

1.基于构造函数的依赖注入：

当容器调用具有多个参数的类构造函数时，就完成了基于构造函数的DI，每个参数表示对其他类的依赖。

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}
<bean id=triangle" class ="com.test.dependencyInjection.Triangle">
        <constructor-arg value="20"/>
  </bean>

2.基于Setter的依赖注入：

基于Setter的DI是在调用无参数构造函数或无参数静态工厂方法来实例化bean之后，通过容器调用bean上的Setter方法来实现的。

public class Triangle{

 private String type;

 public String getType(){
    return type;
  }
 public void setType(String type){          //setter injection
    this.type = type;
  }
 }

<!-- setter injection -->
 <bean id="triangle" class="com.test.dependencyInjection.Triangle">
        <property name="type" value="equivialteral"/>

注：对于强制依赖项使用构造函数参数，对于可选依赖项使用setter，这是一个很好的经验法则。注意，如果我们在setter上使用基于@Required的注释，则可以将setter作为必需的依赖项。

以上所有答案都很好，我的目的是用一种简单的方式解释这个概念，这样任何没有编程知识的人都可以理解这个概念

依赖注入是帮助我们以更简单的方式创建复杂系统的设计模式之一。

我们可以在日常生活中看到这种模式的广泛应用。其中一些例子是录音机、VCD、CD驱动器等。

上图是20世纪中期的便携式磁带录音机。来源

录音机的主要目的是记录或重放声音。

在设计系统时，需要一个卷轴来录制或播放声音或音乐。设计该系统有两种可能性

我们可以把卷轴放在机器里我们可以为卷轴提供一个可以放置的钩子。

如果我们使用第一个，我们需要打开机器来更换卷轴。如果我们选择第二种方式，即为卷轴设置挂钩，那么通过改变卷轴，我们可以获得播放任何音乐的额外好处。并且还将功能减少到只播放卷轴中的任何内容。

类似地，依赖注入是将依赖性外部化以仅关注组件的特定功能的过程，以便独立组件可以耦合在一起形成一个复杂的系统。

我们通过使用依赖注入获得的主要好处。

高内聚力和松耦合。外部化依赖，只关注责任。将事物作为组件，并结合起来形成具有高性能的大型系统。它有助于开发高质量的组件，因为它们是独立开发的，并且经过了适当的测试。如果一个组件出现故障，用另一个组件替换它会有帮助。

如今，这些概念构成了编程界众所周知的框架的基础。Spring Angular等是基于这一概念构建的著名软件框架

依赖注入是一种模式，用于创建其他对象依赖的对象实例，而在编译时不知道将使用哪个类来提供该功能，或者简单地将财产注入对象的方法称为依赖注入。

依赖注入示例

以前我们编写的代码是这样的

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

通过依赖注入，依赖注入器将为我们完成实例化

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 
   
  dependentObject.someMethod();
}

你也可以阅读

控制反转与依赖注入的区别

在进行技术描述之前，首先用一个真实的例子来形象化它，因为你会发现很多技术知识需要学习依赖注入，但大多数人都无法理解它的核心概念。

在第一张图中，假设你有一家拥有很多单位的汽车工厂。汽车实际上是在装配单元中制造的，但它需要发动机、座椅和车轮。因此，装配单元依赖于这些所有单元，它们是工厂的依赖。

你可以感觉到，现在在这个工厂维护所有的任务太复杂了，因为除了主要任务（在组装单元组装汽车）外，你还必须关注其他单元。现在维护成本很高，而且厂房很大，因此需要额外的租金。

现在，看第二张图。如果你找到一些供应商公司，他们会以比你自己生产成本更低的价格为你提供车轮、座椅和发动机，那么现在你就不需要在工厂里生产了。您现在可以为您的装配单元租用一栋较小的建筑，这将减少您的维护任务，并降低额外的租赁成本。现在你也可以只专注于你的主要任务（汽车组装）。

现在我们可以说，组装汽车的所有依赖都是由供应商注入工厂的。这是一个真实的依赖注入（DI）示例。

现在用技术术语来说，依赖注入是一种技术，一个对象（或静态方法）提供另一个对象的依赖。因此，将创建对象的任务传递给其他人并直接使用依赖关系称为依赖注入。

这将帮助您现在通过技术说明学习DI。这将显示何时使用DI，何时不使用DI。

.

使依赖注入概念易于理解。让我们以开关按钮为例来切换（打开/关闭）灯泡。

无依赖注入

Switch需要事先知道我连接到哪个灯泡（硬编码依赖项）。所以

开关->永久灯泡//开关直接连接到永久灯泡，测试不容易

Switch(){
PermanentBulb = new Bulb();
PermanentBulb.Toggle();
}

使用依赖注入

开关只知道我需要打开/关闭传递给我的灯泡。所以，

开关->灯泡1或灯泡2或夜灯泡（注入依赖性）

Switch(AnyBulb){ //pass it whichever bulb you like
AnyBulb.Toggle();
}

修改开关和灯泡的James示例：

public class SwitchTest { 
  TestToggleBulb() { 
    MockBulb mockbulb = new MockBulb(); 

    // MockBulb is a subclass of Bulb, so we can 
    // "inject" it here: 
    Switch switch = new Switch(mockBulb); 

    switch.ToggleBulb(); 
    mockBulb.AssertToggleWasCalled(); 
  } 
}

public class Switch { 
  private Bulb myBulb; 

  public Switch() { 
    myBulb = new Bulb(); 
  } 

  public Switch(Bulb useThisBulbInstead) { 
    myBulb = useThisBulbInstead; 
  } 

  public void ToggleBulb() { 
    ... 
    myBulb.Toggle(); 
    ... 
  } 
}`

“依赖注入”不就是指使用参数化构造函数和公共setter吗？

James Shore的文章展示了以下示例进行比较。

没有依赖注入的构造函数：公共类示例｛私有数据库Thingie myDatabase；public Example（）｛myDatabase=新数据库Thingie（）；} public void doStuff（）｛... myDatabase.getData（）；... } } 具有依赖注入的构造函数：公共类示例｛私有数据库Thingie myDatabase；公共示例（DatabaseThingie使用ThisDatabaseReplace）｛myDatabase=改用此数据库；}public void doStuff（）｛... myDatabase.getData（）；... } }

依赖注入（DI）的全部目的是保持应用程序源代码干净和稳定：

清除依赖项初始化代码无论使用的依赖关系如何稳定

实际上，每个设计模式都将关注点分开，以使将来的更改影响最小的文件。

DI的特定域是依赖配置和初始化的委托。

示例：带有shell脚本的DI

如果您偶尔在Java之外工作，请回想一下源代码在许多脚本语言（Shell、Tcl等，甚至在Python中被误用）中的使用情况。

考虑简单的dependent.sh脚本：

#!/bin/sh
# Dependent
touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

脚本是依赖的：它无法单独成功执行（未定义存档文件）。

可以在archive_files_ip.sh实现脚本中定义archive_files（在本例中使用zip）：

#!/bin/sh
# Dependency
function archive_files {
    zip files.zip "$@"
}

您可以使用一个injector.sh“container”来包装这两个“components”，而不是直接在依赖脚本中源代码化实现脚本：

#!/bin/sh 
# Injector
source ./archive_files_zip.sh
source ./dependent.sh

archive_files依赖项刚刚注入到依赖脚本中。

您可能已经注入了使用tar或xz实现archive_files的依赖项。

示例：删除DI

如果dependent.sh脚本直接使用依赖项，则该方法将被称为依赖项查找（与依赖项注入相反）：

#!/bin/sh
# Dependent

# dependency look-up
source ./archive_files_zip.sh

touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

现在的问题是依赖的“组件”必须自己执行初始化。

“组件”的源代码既不干净也不稳定，因为依赖项初始化中的每一次更改都需要“组件”源代码文件的新版本。

最后一句话

DI并不像Java框架那样被广泛强调和普及。

但这是一种通用的方法，可以解决以下问题：

应用程序开发（单一源代码发布生命周期）应用程序部署（具有独立生命周期的多个目标环境）

仅将配置与依赖项查找一起使用没有帮助，因为每个依赖项的配置参数数量（例如，新的身份验证类型）以及支持的依赖项类型数量（例如新的数据库类型）可能会发生变化。