IoC概念最初出现在过程式编程时代。因此，从历史背景来看，IoC讨论了控制流所有权的倒置，即谁拥有以所需顺序调用函数的责任——无论是函数本身还是应该将其倒置到某个外部实体。

However once the OOP emerged, people began to talk about IoC in OOP context where applications are concerned with object creation and their relationships as well, apart from the control-flow. Such applications wanted to invert the ownership of object-creation (rather than control-flow) and required a container which is responsible for object creation, object life-cycle & injecting dependencies of the application objects thereby eliminating application objects from creating other concrete object.

从这个意义上讲，DI与IoC不同，因为它不是关于控制流的，但是它是一种Io*，即对象创建的所有权倒置。

我解释DI和IoC的方式有什么问题?

DI和IOC是两种主要侧重于提供组件之间的松耦合的设计模式，或者简单地说，这是一种解耦对象之间传统依赖关系的方法，这样对象之间就不会紧密相连。

通过下面的例子，我试图解释这两个概念。

以前我们是这样写代码的

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();
}

使用Dependency注入，依赖注入器将负责对象的实例化

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();
}

上述将控件交给其他容器(例如容器)进行实例化和注入的过程可以称为控制反转，IOC容器为我们注入依赖项的过程可以称为依赖项注入。

IOC是程序控制流颠倒过来的原则:不是由程序员控制程序的流，而是由程序通过减少程序员的开销来控制流程。程序用来注入依赖的过程称为DI

这两个概念一起工作为我们提供了一种编写更加灵活、可重用和封装的代码的方法，这使得它们在设计面向对象的解决方案时成为重要的概念。

也推荐阅读。

什么是依赖注入?

你也可以在这里查看我的一个类似的答案

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

IoC -控制反转是一个通用术语，与语言无关，它实际上不是创建对象，而是描述如何创建时尚对象。

依赖注入是一个具体的术语，我们通过使用不同的注入技术，即Setter注入、构造函数注入或接口注入，在运行时提供对象的依赖关系。

DIP vs DI vs IoC

[依赖倒置原则(DIP)]是SOLID[About]的一部分，它要求你使用抽象而不是实现

依赖注入(DI) -使用聚合而不是组合[关于]在这种情况下，外部对象负责内部的逻辑。哪一种方法使您拥有更动态和更可测试的方法

class A {
  B b

  //injecting B via constructor 
  init(b: B) {
     self.b = b
  }
}

控制反转(IoC)是一个非常高级的定义，它更多地是关于控制流的。最好的例子是控制反转(IoC)容器或框架。例如，GUI是一个框架，你没有一个控制，你能做的一切只是实现框架的接口，当一些动作发生在框架中时，它会被调用。这样，控制权就从应用程序转移到了正在使用的框架中

DIP +

class A {
  IB ib

  init(ib: IB) {
     self.ib = ib
  }
}

你也可以使用:

(工厂方法) (服务定位器) [ioc容器(框架)]

更复杂的例子

多层/模块结构中的依赖规则

伪代码:

interface InterfaceInputPort {
    func input()
}

interface InterfaceOutputPort {
    func output()
}

class A: InterfaceOutputPort {

    let inputPort = B(outputPort: self)

    func output() {
        print("output")
    }
}

class B: InterfaceInputPort {
    let outputPort: InterfaceOutputPort

    init(outputPort: InterfaceOutputPort) {
        self.outputPort = outputPort
    }

    func input() {
        print("input")
    }
}

//ICO, DI,10年前，他们是这样的:

public class  AuditDAOImpl implements Audit{

    //dependency
    AuditDAO auditDAO = null;
        //Control of the AuditDAO is with AuditDAOImpl because its creating the object
    public AuditDAOImpl () {
        this.auditDAO = new AuditDAO ();
    }
}

现在有了Spring 3,4或最新版本，如下图所示

public class  AuditDAOImpl implements Audit{

    //dependency

     //Now control is shifted to Spring. Container find the object and provide it. 
    @Autowired
    AuditDAO auditDAO = null;

}

总的来说，控件从耦合代码的旧概念倒向了使对象可用的Spring等框架。据我所知，这就是IOC和依赖注入我们使用构造函数或setter将依赖对象注入到另一个对象。注入基本上意味着将它作为参数传递。在spring中，我们有基于XML和注释的配置，我们定义bean对象，并通过构造函数或setter注入样式传递依赖对象。

与其直接对比DI和IoC，不如从头开始:每个重要的应用程序都依赖于其他代码段。

所以我写一个类，MyClass，我需要调用一个方法YourService…我需要以某种方式获取YourService的一个实例。最简单、最直接的方法是自己实例化它。

YourService service = new YourServiceImpl();

直接实例化是获取依赖项的传统(过程性)方法。但它有许多缺点，包括MyClass与YourServiceImpl的紧密耦合，这使得我的代码难以更改和测试。MyClass并不关心YourService的实现是什么样子，所以MyClass不想负责实例化它。

我更喜欢把这个责任从MyClass转移到MyClass之外的东西。最简单的方法是将实例化调用(new YourServiceImpl();)移动到其他类中。我可以将这个类命名为Locator，或者Factory，或者其他任何名称;但重点是MyClass不再对YourServiceImpl负责。我颠倒了依赖关系。太好了。

问题是，MyClass仍然负责对定位器/工厂/任何东西的调用。因为我反转依赖关系所做的全部工作就是插入一个中间人，所以现在我耦合到中间人(即使我没有耦合到中间人给我的具体对象)。

我并不真正关心依赖项来自何处，因此我宁愿不负责进行检索依赖项的调用。仅仅反转依赖本身是不够的。我想反转整个过程的控制。

What I need is a totally separate piece of code that MyClass plugs into (call it a framework). Then the only responsibility I'm left with is to declare my dependency on YourService. The framework can take care of figuring out where and when and how to get an instance, and just give MyClass what it needs. And the best part is that MyClass doesn't need to know about the framework. The framework can be in control of this dependency wiring process. Now I've inverted control (on top of inverting dependencies).

将MyClass连接到框架中有不同的方法。注入就是这样一种机制，通过这种机制，我只需声明一个我期望框架提供的字段或参数，通常是在它实例化MyClass时。

我认为所有这些概念之间的关系层次比这个线程中的其他图表所显示的要稍微复杂一些;但其基本思想是，这是一种等级关系。我觉得这和野外的DIP是同步的。