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

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

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

你也可以阅读

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

这意味着对象应该只具有完成其工作所需的依赖项，并且依赖项应该很少。此外，如果可能的话，对象的依赖关系应该是接口，而不是“具体”对象。（具体对象是用关键字new创建的任何对象。）松散耦合促进了更高的可重用性，更容易维护，并允许您轻松地提供“模拟”对象来代替昂贵的服务。

“依赖注入”（DI）也称为“控制反转”（IoC），可以用作鼓励这种松散耦合的技术。

实施DI有两种主要方法：

构造函数注入设值注入

构造函数注入

这是一种将对象依赖关系传递给构造函数的技术。

注意，构造函数接受接口而不是具体对象。此外，请注意，如果orderDao参数为空，则会引发异常。这强调了接受有效依赖的重要性。在我看来，构造函数注入是赋予对象依赖关系的首选机制。在调用对象时，开发人员很清楚需要向“Person”对象提供哪些依赖关系才能正确执行。

沉淀剂注入

但是考虑下面的例子……假设您有一个类，它有十个没有依赖关系的方法，但是您要添加一个新方法，它确实依赖于IDAO。您可以将构造函数更改为使用构造函数注入，但这可能会迫使您更改所有的构造函数调用。或者，您可以添加一个新的构造函数来获取依赖项，但是开发人员如何轻松地知道何时使用一个构造函数而不是另一个构造函数。最后，如果依赖项的创建成本很高，为什么要创建它并传递给构造函数，因为它可能很少使用？“Setter Injection”是另一种DI技术，可用于此类情况。

Setter注入不会强制将依赖项传递给构造函数。相反，依赖项被设置到需要的对象公开的公共财产上。正如前面所暗示的，这样做的主要动机包括：

支持依赖注入而无需修改遗留类的构造函数。允许在需要时尽可能晚地创建昂贵的资源或服务。

下面是上述代码的示例：

public class Person {
    public Person() {}

    public IDAO Address {
        set { addressdao = value; }
        get {
            if (addressdao == null)
              throw new MemberAccessException("addressdao" +
                             " has not been initialized");
            return addressdao;
        }
    }

    public Address GetAddress() {
       // ... code that uses the addressdao object
       // to fetch address details from the datasource ...
    }

    // Should not be called directly;
    // use the public property instead
    private IDAO addressdao;

我在松耦合方面发现了一个有趣的例子：

来源：了解依赖注入

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

例如，考虑Car对象。

汽车依靠轮子、发动机、燃料、电池等运转。传统上，我们定义此类依赖对象的品牌以及Car对象的定义。

无依赖注入（DI）：

class Car{
  private Wheel wh = new NepaliRubberWheel();
  private Battery bt = new ExcideBattery();

  //The rest
}

在这里，Car对象负责创建从属对象。

如果我们希望在初始NepaliRubberWheel（）穿孔后更改其从属对象的类型（例如Wheel），该怎么办？我们需要重新创建Car对象及其新的依赖项，例如ChineseRubberWheel（），但只有Car制造商才能做到这一点。

那么依赖注入为我们做了什么。。。？

当使用依赖注入时，对象在运行时而不是编译时（汽车制造时）被赋予依赖性。因此，我们现在可以随时更改轮子。在这里，相关性（轮子）可以在运行时注入Car。

使用依赖注入后：

这里，我们在运行时注入依赖项（Wheel和Battery）。因此有了这个词：依赖注入。我们通常依赖于Spring、Guice、Weld等DI框架来创建依赖关系并在需要时注入。

class Car{
  private Wheel wh; // Inject an Instance of Wheel (dependency of car) at runtime
  private Battery bt; // Inject an Instance of Battery (dependency of car) at runtime
  Car(Wheel wh,Battery bt) {
      this.wh = wh;
      this.bt = bt;
  }
  //Or we can have setters
  void setWheel(Wheel wh) {
      this.wh = wh;
  }
}

其优点是：

分离对象的创建（换句话说，将使用与对象的创建分开）能够替换依赖项（例如：车轮、电池），而不改变使用它的类（汽车）促进“代码到接口而不是实现”原则在测试期间创建和使用模拟依赖关系的能力（如果我们想在测试期间使用模拟轮而不是真实实例，我们可以创建模拟轮对象并让DI框架注入Car）

依赖注入是解决“依赖混淆”需求的一种可能方案。依赖性混淆是一种将“明显”性质从向需要依赖性的类提供依赖性的过程中去除的方法，因此在某种程度上混淆了向所述类提供所述依赖性。这不一定是坏事。事实上，通过混淆向类提供依赖项的方式，类外部的某个东西负责创建依赖项，这意味着在各种情况下，可以向类提供不同的依赖项实现，而不需要对类进行任何更改。这对于在生产和测试模式之间切换非常有用（例如，使用“模拟”服务依赖）。

不幸的是，糟糕的部分是，有些人认为你需要一个专门的框架来进行依赖性混淆，如果你选择不使用特定的框架来做，那么你在某种程度上就是一个“低级”程序员。另一个非常令人不安的神话是，依赖性注入是实现依赖性混淆的唯一方法。这显然是历史性的，显然是100%错误的，但你很难说服一些人，依赖项注入可以替代依赖项混淆需求。

多年来，程序员们已经了解了依赖性混淆的需求，在考虑依赖性注入之前和之后，许多替代解决方案都已经发展起来。有工厂模式，但也有许多使用ThreadLocal的选项，其中不需要对特定实例进行注入-依赖关系被有效地注入到线程中，这样做的好处是使对象（通过方便的静态getter方法）可用于任何需要它的类，而无需向需要它的类别添加注释并设置复杂的XML“粘合”以实现这一点。当持久性需要依赖项（JPA/JDO或其他）时，它允许您更容易地实现“跨持久性”，并且域模型和业务模型类完全由POJO组成（即没有特定于框架的/锁定在注释中的）。

依赖注入（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框架那样被广泛强调和普及。

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

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

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

依赖注入是与Spring框架相关概念的核心。在创建任何项目的框架时，Spring都可能发挥重要作用，而依赖注入就是其中之一。

实际上，假设在java中，您创建了两个不同的类，即类A和类B，并且无论类B中有什么函数，您都希望在类A中使用，所以此时可以使用依赖注入。在这里，您可以将一个类的对象放入另一个类中，就像您可以将整个类注入另一个类别中以使其可访问一样。通过这种方式可以克服依赖性。

依赖注入只是将两个类粘合在一起，同时保持它们的分离。