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

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

我们可以在日常生活中看到这种模式的广泛应用。其中一些例子是录音机、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的特定域是依赖配置和初始化的委托。

示例：带有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框架那样被广泛强调和普及。

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

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

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

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

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

我们可以在日常生活中看到这种模式的广泛应用。其中一些例子是录音机、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();
}

你也可以阅读

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

到目前为止，我找到的最好的定义是詹姆斯·肖尔的定义：

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

马丁·福勒的一篇文章可能也很有用。

依赖注入基本上是提供对象所需的对象（其依赖项），而不是让它自己构造它们。这是一种非常有用的测试技术，因为它允许对依赖项进行嘲笑或清除。

依赖关系可以通过多种方式注入到对象中（例如构造函数注入或setter注入）。甚至可以使用专门的依赖注入框架（例如Spring）来实现这一点，但它们肯定不是必需的。您不需要这些框架进行依赖注入。显式实例化和传递对象（依赖项）与框架注入一样好。

这是我见过的关于依赖注入和依赖注入容器的最简单的解释：

无依赖注入

应用程序需要Foo（例如控制器），因此：应用程序创建Foo应用程序调用FooFoo需要Bar（例如服务），因此：Foo创建BarFoo调用Bar酒吧需要Bim（服务、存储库，…），因此：条形图创建Bim酒吧有点事

使用依赖注入

应用程序需要Foo，需要Bar，需要Bim，因此：应用程序创建Bim应用程序创建Bar并赋予它Bim应用程序创建Foo并给它Bar应用程序调用FooFoo调用Bar酒吧有点事

使用依赖注入容器

应用程序需要Foo，因此：应用程序从容器中获取Foo，因此：容器创建Bim容器创建Bar并赋予它Bim容器创建Foo并给它Bar应用程序调用FooFoo调用Bar酒吧有点事

依赖注入和依赖注入容器是不同的：

依赖注入是一种编写更好代码的方法DI容器是帮助注入依赖项的工具

您不需要容器来执行依赖注入。然而，容器可以帮助您。

我能想到的最好的类比是手术室中的外科医生和他的助手，在那里，外科医生是主要的人，他的助手在他需要时提供各种手术组件，以便外科医生能够专注于他最擅长的一件事（手术）。如果没有助手，外科医生每次需要时都必须自己取下部件。

简而言之，DI是一种通过向组件提供依赖组件来消除组件获取依赖组件的常见额外责任（负担）的技术。

DI使您更接近单一责任（SR）原则，就像外科医生可以专注于外科手术一样。

何时使用DI：我建议在几乎所有的生产项目（小型/大型）中使用DI，尤其是在不断变化的业务环境中：）

原因：因为您希望代码易于测试、可模拟等，以便快速测试更改并将其推向市场。此外，当你有很多很棒的免费工具/框架来支持你的代码库之旅时，你为什么不这样做呢。